Fixed ClientSession initialization warning

[AraHaan]

This fixes an issue with ClientSession throwing a warning when feeding
an event loop into it when calling it from a normal function. This
should help silence annoying warnings for libraries that "lazy"
initializes ClientSession and properly closes the session and handles
it. Now those libraries would have no need for useless bug reports.

What do these changes do?

Fixes the warning when calling a ClientSession instance with an event loop that is passed to the class.

Are there changes in behavior for the user?

No, just adds more control over the ClientSession instance.

Related issue number

#1468 (comment)

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Add yourself to CONTRIBUTORS.txt
  • The format is <Name> <Surname>.
  • Please keep alphabetical order, the file is sorted by names.
• Add a new entry to CHANGES.rst
  • Choose any open position to avoid merge conflicts with other PRs.
  • Add a link to the issue you are fixing (if any) using #issue_number format at the end of changelog message. Use Pull Request number if there are no issues for PR or PR covers the issue only partially.

[AraHaan]

@asvetlov There seems to be an issue with some tests on AppVeyor. However I know these should succeed.

[codecov-io]

Codecov Report

Merging #1572 into master will increase coverage by 0.03%.

@@            Coverage Diff             @@
##           master    #1572      +/-   ##
==========================================
+ Coverage   98.54%   98.57%   +0.03%     
==========================================
  Files          32       30       -2     
  Lines        7265     7107     -158     
  Branches     1208     1181      -27     
==========================================
- Hits         7159     7006     -153     
+ Misses         61       60       -1     
+ Partials       45       41       -4

Impacted Files	Coverage Δ
aiohttp/client.py	100% <100%> (ø)	✅
aiohttp/helpers.py	98.78% <ø> (-0.51%)	❌
aiohttp/multipart.py	93.51% <ø> (-0.5%)	❌
aiohttp/streams.py	98.6% <ø> (-0.23%)	❌
aiohttp/web_urldispatcher.py	99.6% <ø> (-0.2%)	❌
aiohttp/protocol.py	96.78% <ø> (-0.02%)	❌
aiohttp/web.py	100% <ø> (ø)	✅
aiohttp/cookiejar.py	100% <ø> (ø)	✅
aiohttp/_ws_impl.py	100% <ø> (ø)	✅
... and 9 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 63acb3e...3d6ea46. Read the comment docs.

[AraHaan]

@fafhrd91 You been breaking the PR. kek

btw did you fix the problem with this on the first commit on this PR yet?

[fafhrd91]

i do not understand you

[AraHaan]

Look at https://ci.appveyor.com/project/asvetlov/aiohttp/build/1.1.0a0.dev3847/job/9pxom9fkwakhiodo It shows 2 recive tests failing. With test_receive_timeout and test_custom_receive_timeout being the tests that sometimes fail in Appveyor.

[fafhrd91]

last build is green

[AraHaan]

Yeah, travis works just AppVeyor sometimes fails on me for no reason at all.

[AraHaan]

@fafhrd91 turns out that it seems the test failure on AppVeyor seems to now be fixed.

[lock]

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.