feat(ngrok): add aws-lc-rs and ring features

[CBenoit]

Closes #177

These features allow the consumer to choose between aws-lc-rs and ring rustls backends.

[bmpngrok]

Thanks for the PR, @CBenoit. I'll follow up within the next day. The engineer who made this change isn't with the company anymore, and I'm trying to verify that the decision to support only aws-lc-rs v. ring was an oversight instead of intentional.

[CBenoit]

Thanks for the PR, @CBenoit. I'll follow up within the next day. The engineer who made this change isn't with the company anymore, and I'm trying to verify that the decision to support only aws-lc-rs v. ring was an oversight instead of intentional.

Thank you!!

Since this engineer is not with you anymore, let me give you extra context.

At least for libraries, from experience it's often an oversight, and if not its often a "let's not care just right now" thing, as there is no benefit other than reducing the number of features. Hopefully, it does not really add tricky conditional code (although the verification that the right set of features are enabled for all relevant crates itself can be tricky).

Last year, the rustls ecosystem took the decision to change the default backend from rustls to aws-lc-rs, because the latter is better maintained, there is formal verification efforts, and it supports FIPS, although that's yet a different backend, which may require extra feature flags. The only thing is: switching to aws-lc-rs, was not a conscious move for many folks. Simply updating dependencies and/or transitive dependencies caused many people to switch to aws-lc-rs "automatically" (and sometimes to have both ring and aws-lc-rs in their dependencies, even though only one is automatically selected), unless they would know about the decision of the rustls project somehow (reading the CHANGELOG, or being involved). The many libraries building upon rustls for TLS then slowly started adding feature flags to control the backend, but it took some time for this to bubble up to all the relevant places such as future-rustls or reqwest.

ngrok-rs recently updated its dependencies, and I believe it simply followed the same course as many other crates last year by not exposing extra flags to control the backend.

I think it also makes sense to expose a feature flag to not set any backend at all, letting the final consumer choose which one to enable by calling rustls APIs manually at the start of the program. I can add that too if you want. (For instance, reqwest provides a feature called rustls-tls-no-provider just for that).

[bmpngrok]

Thanks for the explanation, @CBenoit. That all makes sense. I'm working on getting our CI pipeline fixed this morning so I can get your other PR actually deployed to crates.io. Once I've got that sorted and verified our pipelines are all back up, I'll get this merged