Add a feature flag for forcing selection of openssl

[eranrund]

It appears that on Mac there is no support for TLSv1.3.
This has been surfaced in a few PRs (e.g. #278 #235 #159).
It appears that if I force the build to use openssl on Mac, I can in fact connect to TLSv1.3 HTTP servers.

The way I tested this is with the reqwest crate. When built with the stock version of this crate, I get a bad protocol version error. If I then use a [patch.crates.io] to switch to this branch, and enable the force-openssl feature, I can now successfully connect to my TLSv1.3 server.

It's not the most elegant approach but I'm hoping that perhaps you'll be open to it.

Thank you!

[sfackler]

If you want to use OpenSSL, you should use rust-openssl instead of this library.

[eranrund]

However there's currently no way to get something like reqwest which uses this crate to use OpenSSL on Mac...

[sfackler]

Then have it use rustls which also supports TLS 1.3: https://github.com/seanmonstar/reqwest/blob/master/Cargo.toml#L41

[schmonz]

My use case is different from @eranrund's, but I'm also interested in a build-time flag to force the backing implementation to OpenSSL.

I'm not (yet) a Rust developer, but I maintain a bunch of packages (some written in Rust) for a cross-platform Unix package system. As you might expect, we generally want our packaged software to be linking with the same libraries regardless of platform. I appreciate that that's precisely not what rust-native-tls is here for. By the same token, I'm not here to try to persuade upstreams not to choose rust-native-tls.

I think you may have an inexpensive way to help packagers square this circle, though, because I understand the value of rust-native-tls to be in three parts:

1. A desirable-to-use abstraction layer
2. Multiple backing implementations
3. An opinionated default choice of implementation

By making (3) easy to override, all the software out there using rust-native-tls can easily be built for contexts in which sameness across platforms is valued (and expected) more highly than native-ness within platforms.

I know that's not the context you're aiming at with this project. I hope my request might be cheap enough, and beneficial enough to the software ecosystem, that you might decide to accommodate anyway. Thanks for your code and your consideration.