feat: updates for rustls 0.23

[jbr]

This PR is an attempt at updating futures-rustls for rustls 0.23.

• Switches the default crypto provider to aws-lc-rs to track rustls' default. (feat: change default crypto provider to match rustls' tokio-rustls#50 for parity)
• Adds fips and logging features so crates don't need to depend on rustls just to enable those features without using rustls directly in code (feat: add fips pass-through feature tokio-rustls#49 for parity)
• Sends AcceptedAlerts
  • Adds an optional AcceptedAlert to the MidHandshake::Error state Adds a SendAlert variant to MidHandshake per Take rustls 0.23 tokio-rustls#44, with the changes in fix: check for ErrorKind::WouldBlock in MidHandshake::SendAlert poll tokio-rustls#47
  • Tracks an Option<Error, AcceptedAlert> on LazyConfigAcceptor in order to send the AcceptedAlert, tracking the changes in Fix: Check for ErrorKind::WouldBlock in LazyConfigAcceptor tokio-rustls#48
• Adds a pub(crate) common::SyncWriteAdapter and uses it instead of an identical function-local Writer type, tracking the changes in Take rustls 0.23 tokio-rustls#44
• Uses the existing SyncReadAdapter instead of an identical function-local Reader type tracking the changes in Take rustls 0.23 tokio-rustls#44
• Addresses redundant-import compiler warnings introduced in a recent nightly
• Introduces several rustfmt-caused import order changes
• Updates a repository link to rustls/rustls
• Takes poll_vectored_write changes from Forward vectored writes tokio-rustls#45
• Takes poll_close changes from Ignore NotConnected error in poll_shutdown() tokio-rustls#42
• Adds an aws_lc_rs alias for aws-lc-rs because some people use underscores for features and crate names

Let me know if you'd like me to split any of these out into distinct PRs or to back them out of this PR.

[quininer]

I hope that futures-rustls and tokio-rustls keep isomorphic in implement to reduce maintenance costs.

You can refer to this to implement it. rustls/tokio-rustls#44

[jbr]

Specifically you mean adding a variant instead of using an option? Will do.

Why don't these crates share code if they're intended to be largely identical? Or have one crate and enable the async traits with a feature flag? Or at the least keep them in a shared workspace folks remember to update both?

I also believe there's a bug in the other implementation, in that it doesn't check if the alert returns WouldBlock and return pending. Should I PR that over there?

[jbr]

Switched to using a MidHandshake::SendAlert variant instead of a MidHandshake::Error { alert: Option<AcceptedAlert>,.. }

[jbr]

@quininer @djc Is this PR good to go? I believe it tracks all of the changes that have been made in tokio-rustls for rustls 0.23

[quininer]

There are some other changes in tokio-rustls (poll_shutdown, vectored write), would you like to work on it in this PR?

[jbr]

@quininer added cb69b96 and 02417c3 with vectored_write and poll_close changes from tokio-rustls

[quininer]

I'll take a look tonight.

[quininer]

Thank you!