What should we do with urllib3's securetransport and pyopenssl support?

[njsmith]

urllib3 has code in urllib3.contrib to support using securetransport or pyopenssl for TLS, instead of the default stdlib ssl module.

This is accomplished by doing some pretty intrusive monkeypatching of urllib3's low level networking code. In hip we've replaced all that low-level networking code, and we additionally have the complication that now we have multiple different networking backends. So the existing code needs to change somehow.

I guess the first question is: should we keep it at all? Can someone summarize the problems that it's solving? I feel like there's probably a bunch of important but subtle details and history here that I don't understand, but we need to before making a decision.

If we do keep it, does it only need to work for the sync backend, or does it need to work for the async backends too? Presumably the answer will depend on why it's useful in the first place.

And if we do keep it, can we not do wacky monkeypatching stuff? I'm not a fan of contrib modules in general... I feel like either we should support something properly as a full-fledged feature, or not support it.

[sethmlarson]

I'm in favor of removal for now, they'll require a ton of rework to make them work in Hip. If needed and possible we can reintroduce them.

I'm also in favor of removing our SOCKS support and reintroducing SOCKS support outside of contrib using socksio.