Add deferredssl

[ghost]

Wraps ssl in a deferred wrapper.
aiohttp does not require SSL to function. The codepaths involved with
SSL will only be hit upon SSL usage. Using a wrapper allows installs
that don't use SSL to function (without erroring on import) and still
allows full function on SSL enabled systems.

What do these changes do?

Are there changes in behavior for the user?

Related issue number

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
  • The format is <Name> <Surname>.
  • Please keep alphabetical order, the file is sorted by names.
• Add a new news fragment into the changes folder
  • name it <issue_id>.<type> for example (588.bug)
  • if you don't have an issue_id change it to the pr id after creating the pr
  • ensure type is one of the following:
    • .feature: Signifying a new feature.
    • .bugfix: Signifying a bug fix.
    • .doc: Signifying a documentation improvement.
    • .removal: Signifying a deprecation or removal of public API.
    • .misc: A ticket has been closed, but it is not of interest to users.
  • Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files."

[asvetlov]

What is your use case?
I pretty sure all Python interpreters are shipped with ssl support nowdays.

[ghost]

My use case is a bit contrived. I was trying to use this with buildozer / python-for-android, which by default don't include ssl (but can).

Just figured that in case SSL isn't available (although, like you pointed out, it almost always is), seems better to only fail when it's required.

[asvetlov]

I see ssl module is needed two times: in connector.py and worker.py.

I believe we need something like:

try:
    import ssl
except ImportError:
    ssl = None

and

if ssl is None:
    raise RuntimeError("SSL is not supported:)

Adding a new module is overengineering.

[ghost]

The only reason I opted for a module was to be a bit forward looking (and DRY).
But, whatever fits best with the project makes most sense.

[asvetlov]

@machina-widmo would you rewrite a PR for using approach proposed by me?
I really don't like deferredsll.py.

[ghost]

I went back and fixed up only the actual "deployable" runtime code.
Anywhere else, I don't think it's necessary as they are either examples, or tests.

May be worth doing conditional imports for the tests so at least the tests could run and fail on usage.

[asvetlov]

Merged to master from command line.

Thanks for contribution.

[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.