Proposal: Share code between tokio-rustls and futures-rustls

Currently, tokio-rustls and futures-rustls share very similar code duplicated across two different repositories. Every PR that is opened to one of them must be manually duplicated in other in order to ensure parity. As it currently stands, the two test suites have diverged and futures-rustls has significantly less coverage.

It seems like it would make maintenance easier if the two crates shared as much implementation code as possible. I could imagine a few ways of doing this, and would happily contribute any of them.

The easiest path forward would probably be introducing a third crate that has feature flags for tokio and futures. The two existing crates would reexport everything from the third crate, allowing users to continue depending on tokio-rustls and futures-rustls as is, but they would be light shims on top of the unified crate.

If the smol team were willing to part with it, the common crate could take the name async-rustls and the shim crates of tokio-rustls and futures-rustls could be deprecated in preference to just setting the desired feature flags on the new common-implementation async-rustls.

If all three crates were in a shared workspace, as an additional distinct step from the above, CI could ensure that every change to the shared implementation crate worked correctly with both flavors of async trait. The challenge here would be retaining history, but it seems like the histories of the two repositories are very similar, so someone looking into the past could find answers just as well by looking at tokio-rustls' history if the futures-rustls repository were archived

Start by comparing the duplicated implementation and the diverged test suites in the tokio-rustls and futures-rustls repositories. Read the issue discussion and confirm which shared-crate or workspace design maintainers want before making changes. Done means the chosen implementation is shared while both async flavors retain their existing crate interfaces and have equivalent test coverage.