Allow consumers of the library to opt out of native-tls

[xen0n]

Currently the Cargo.toml pulls in reqwest with default features enabled, which means native_tls is pulled in, hence an OpenSSL for any Linux target, while the user should be in control of reqwest's other features. A closed issue of reqwest pointed me to this library.

This complicates downstream programs that are benefiting from e.g. simple cross-compilation to x86_64-unknown-linux-musl, and not having elaborated cross-compilation sysroot setup. For example, I just had to add Aliyun support to my acmed-dns-helper-dnspod project (the name is no longer accurate), and my static musl builds broke due to this.

As it's impossible to override this without forking the project (see the StackOverflow answer), could you consider minimizing used features and releasing a patch version?

[edsky]

我看你母语是中文，我就直接说中文吧，免得翻译。

x86_64-unknown-linux-musl 编译可以直接用openssl的vendored模式，不用修改任何东西，只需要你依赖就可以了
添加以下行到你的依赖即可

openssl = { version = "0.10", features = ["vendored"] }

如果有啥问题可以再次提出！

[xen0n]

我看你母语是中文，我就直接说中文吧，免得翻译。

x86_64-unknown-linux-musl 编译可以直接用openssl的vendored模式，不用修改任何东西，只需要你依赖就可以了
添加以下行到你的依赖即可

openssl = { version = "0.10", features = ["vendored"] }

如果有啥问题可以再次提出！

构建可能可以通过，但这样做可能剥夺了我想最小化我的可执行文件大小的可能性。。。

[edsky]

那我加一个特征吧，你要透过哪个特征？最小化好像没有影响吧

[xen0n]

那我加一个特征吧，你要透过哪个特征？

仿照 reqwest 处理即可

最小化好像没有影响吧

理想情况是当一个人选用 rustls 时，依赖图中就没有 openssl；反之亦然。能这样且使用姿势与 reqwest 类似就最好了。