[websocket] Switch async-tls to futures-rustls

[quininer]

This PR replace async-tls with async-rustls. async-rustls is based on a newer version of tokio-rustls, which fixes many known bugs.

[quininer]

Oh, I noticed that async-rustls is still using rustls 0.18 ...

[romanb]

Thanks, looks innocent enough to me. I'm not familiar with the details of async-tls and async-rustls, so I take your word for it that this is a step forward. Since async-tls seems to look for new maintainers, this may be a good change in any case. I don't think the rustls version used matters, unless 0.19 has some critical patches over 0.18.

[quininer]

The maintenance status of async-rustls does not seem to be so good, I will pick up futures-rustls again on the weekend.

[romanb]

Thanks and apologies for the late reply. So just to summarise before proceeding here, there now is async-tls, async-rustls and futures-rustls, all derived from different versions of tokio-rustls. You suggest to use futures-rustls because it is based off a much later version of tokio-rustls, hence fixing bugs, and because the former two are not well maintained. Is that a correct summary? Just for reference, what are some of the bugs that are unresolved in async-tls? Is there also a difference in goals / ambitions between these libraries that influence the preferred choice?

cc @mxinden @tomaka

[quininer]

You can see many issues in the old tokio-rustls repository (quininer/tokio-rustls#32 quininer/tokio-rustls#34 quininer/tokio-rustls#55). AFAIK, async-tls does not perform any backport.

async-rustls looks good, but at the time it only supports rustls 0.18, I don't want to use two versions rustls.

[mxinden]

Sorry, I confused async-rusttls with futures-rustls and thus thought #1889 (comment) suggests to put this on hold. Never mind.