Requests 2.24.0 removed necessary namespace for other modules

Commit https://github.com/psf/requests/commit/db47b9b4a0c5877fb97f64ac442757604c4c45cc made import of pyopenssl optional.
Some modules rely on the created requests namespace created via `from urllib3.contrib import pyopenssl` which is now uncertain to be imported, depending on ssl SNI support.

While this does not seem to affect CPython, it can affect programs that have been compiled with Nuitka, that may result in the following error:
```
ModuleNotFoundError: No module named 'requests.packages.urllib3.contrib.pyopenssl
```

This may also happen with frozen CPython (pyinstaller, cx_freeze...), although I didn't check this.

Indeed I've tried to manually import `requests.packages.urllib3.contrib.pyopenssl` in my script to 'force' it to be present.

While I've tracked the issue down, I've tested various Python versions:
- Python 3.7.6 x64 & x32
- Python 3.8.3 x64
- Python 3.8.5 x64 & x32

For every Python version, I also tested the following Nuitka versions:
- Nuitka 0.6.6
- Nuitka 0.6.7
- Nuitka 0.6.8

I guess all modules that rely on requests might use that namespace too.
I think there are two ways to fix the issue (I've verified, both methods work):

1. Make the pyopenssl import mandatory in requests module
2. Fix all requests dependant modules that use that namespace

In my case, using requests_pkcs12 module, I can fix the namespace error by replacing the import from requests by an import from urllib3 in `requests_pkcs12.py`:
```
#from requests.packages.urllib3.contrib.pyopenssl import PyOpenSSLContext
from urllib3.contrib.pyopenssl import PyOpenSSLContext
```
@vog, could you proof read me here ?

Any ideas what's the 'good' choice ?

## Reproduction Steps

Here's a minimal self contained example, but it will need a server asking for a client certificate, and a PKCS12 client certificate.

```#!/usr/bin/env python

from requests_pkcs12 import Pkcs12Adapter
import requests


api_session = requests.Session()

api_session.mount('https://my_server.fqdn',
                                       Pkcs12Adapter(pkcs12_filename='/path/to/my/client/cert.p12',
                                                     pkcs12_password='my_pkcs12_password'))
r = api_session.post('https://my_server.fqdn' + '/api/login')
print('request result %s' % r.text)

```

When compiled with:
```
python -m nuitka --standalone --include-module=urllib3 my_test_program.py
```

Program execution will fail with `ModuleNotFoundError: No module named 'requests.packages.urllib3.contrib.pyopenssl'`


## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "3.0"
  },
  "idna": {
    "version": "2.10"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.8.5"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "1010107f",
    "version": "19.1.0"
  },
  "requests": {
    "version": "2.23.0"
  },
  "system_ssl": {
    "version": "1010107f"
  },
  "urllib3": {
    "version": "1.25.10"
  },
  "using_pyopenssl": true
}
```



So the import removed would be `requests.pyopenssl` not `requests.packages.urllib3.contrib.pyopenssl` if I'm reading things correctly. How would removing that import cause the import that's occuring within `requests/packages.py` to not be available?

From `requests/packages.py` the import states `from urllib3.contrib import pyopenssl` which indeeds should endup as `requests.pyopenssl`.

The thing here is that compilers / freezers need to track down which modules are imported.
Making the import optional will make the compiler fail to do so.
Adding the import manually (or specifying it as optin to the compiler) doesn't work either, as it won't be in the request namespace.


Hi, author of [requests_pkcs12](https://github.com/m-click/requests_pkcs12) here.

I believe this should be fixed on our side. I see no reason why we couldn't just change

    from requests.packages.urllib3.contrib.pyopenssl import PyOpenSSLContext

to

    from urllib3.contrib.pyopenssl import PyOpenSSLContext

on our side. So I performed that change (see m-click/requests_pkcs12#22) and released a new version 1.8:

* [requests_pkcs12](https://pypi.org/project/requests-pkcs12/)

Thanks @vog 
@psf team, sorry for the noise. Hopefully other modules don't share the same namespace requirements, at least they might find the answer here.

@deajan @vog So it's a good idea (if you can) to not use the fake-bundled `urllib3` module within `requests.packages`, however we still totally support that as a valid import.  If we were to break that functionality "in-general" there'd be a firestorm of users raising the issue here instead of this single reported issue.

So why did our removal of importing `pyopenssl` to the `requests` namespace affect anything with the usage of `requests.packages.urllib3.contrib.pyopenssl`? If I had to guess right now it's something that the Python program freezer Nuitka isn't detecting properly? I have less experience with Python program freezers however I do know they do some interesting things to "detect" imports. Is this something you're interested in looking into further @deajan ?

@sethmlarson Not enough qualified for that job sadly. @kayhayen, any ideas ?

@deajan I think there is a meta path based loader there, that works best if the module is included by accident. We have an implicit dependency in the Nuitka code:

``        "requests.packages.urllib3.contrib.pyopenssl": "urllib3.contrib.pyopenssl", ```

If there's more to add, that's fine. In the development version, Nuitka no longer insists on these to be truly there, so removing them will not harm.

Yours,
Kay


Given this seems to be resolved with Nuitka and isn't directly a defect with Requests, I'm going to resolve. Let us know if there's something missed.