use features to make tokio-rustls compatible with `futures` interface

[Congyu]

I have forked this repo and made a commit 2fb62ea which added a new feature called "use-futures" that makes this library compatible with futures interface and the async-std library.

The downside of this change is that it involves several blocks of duplicate code due to the different naming of AsyncWrite trait, where poll_shutdown is called poll_close in futures crate. This could make the code base harder to maintain. Moreover, the testing part of this crate can be more cumbersome too, since it should involve testing under two different async frameworks (For the moment, there are still two tests under tokio that I failed to migrate to async-std).

The upside of such a change is obviously that it enables users of futures inteface to benefit from the update in this repository, and also enables them to contribute to this library too.

The diff in Cargo.toml looks like this:

 tokio = "1.0"
 rustls = { version = "0.20", default-features = false }
 webpki = "0.22"
-
+futures = { version = "0.3", optional = true }
 [features]
 default = ["logging", "tls12"]
+use-futures = ["futures"]
 dangerous_configuration = ["rustls/dangerous_configuration"]
 early-data = []
 logging = ["rustls/logging"]
 tls12 = ["rustls/tls12"]

 [dev-dependencies]
 tokio = { version = "1.0", features = ["full"] }
+tokio-async-std = "1"
 futures-util = "0.3.1"
 lazy_static = "1"
 webpki-roots = "0.22"

[Dirkjan Ochtman]

Why not use https://github.com/quininer/futures-rustls?

[Congyu]

Well, futures-rustls is a very good crate for sure. But I still think it is foreseeable that in the future futures-rustls will have to be manually kept up to date with tokio-rustls when there are bug fixes and so on, or it will be out of date like async-tls.

I am not sure whether it is better just so, to have these two repos left separate, or instead, go on as a single code base. The name of the crate perhaps indicates that these two should better be kept separated (why should tokio-rustls, with tokio in its name, support futures?)

[Dirkjan Ochtman]

The futures-rustls crate shares a maintainer with tokio-rustls, so I don't think it will be an issue.

[Lucio Franco]

This crate is designed to be light weight wrapper for tokio so I don't think it makes sense to add the additional complexity to support other futures runtimes. I believe there has been some effort somewhere else in the ecosystem to unify this work but I don't believe that that belongs under the tokio org at the moment.