The singular purpose of this crate should be to integrate Tokio and
Rustls. Therefore, any feature that isn't about making Rustls work
nicely with Tokio should be assumed a priori to be out of scope.
In particular, it is out of scope for tokio-rustls to provide APIs to
control SNI behavior. Instead, the application should configure
Rustls's SNI behavior using Rustls's configuration APIs, and pass the
configuration to tokio-rustls. Similarly, it is out of scope for
tokio-rustls to provide APIs to control the certificate validation
behavior. Instead, the application should configure certificate
validation using Rustls's APIs. Perhaps there should be a crate that
makes it convenient to do "dangerous" certificate validation, but IMO
that shouldn't be tokio-rustls, but a different one.
FWIW, the `danger` API was inherited from tokio-tls, and I'm working on
making an analogous change there.
