AsyncRead, AsyncWrite updates using async_fn_in_trait

[tgross35]

Is your feature request related to a problem? Please describe.

AFIT will be stable in 1.75 rust-lang/rust#115822. I think this allows for simplification of some of the traits in tokio::io and elsewhere.

Describe the solution you'd like

E.g. AsyncRead::poll_read should be able to have an aync fn signature and return Result<usize>, rather than taking cx and returning a Poll.

This will make it easier for users to make use of the trait directly, as opposed to going through other tokio function calls.

Describe alternatives you've considered

I do not know what the exact signatures would look like. This would of course be a MSRV breaking change so it may need a feature flag.

[Darksonn]

This isn't going to happen. The AsyncRead/AsyncWrite traits cannot be changed due to backwards compatibility.

Besides, even if we could change it, we wouldn't want to because using async_fn_in_trait for these traits would remove some of their features:

• You would no longer be able to read and write at the same time, because the read/write futures mutably borrow the IO resource. E.g., the tokio::io::split utility becomes impossible.
• You would give up cancellation safety, so you could no longer safely read or write in a tokio::select!.
• You would give up dynamic dispatch, so you could no longer use Pin<Box<dyn AsyncRead>>.

Possibly the methods on the Ext traits could be replaced with async_fn_in_trait, but that's a different matter and would mostly only affect how the documentation is rendered.

This would of course be a MSRV breaking change so it may need a feature flag.

Our MSRV policy would prevent us from adopting this for six months, but it's not just an MSRV-breaking change. It's a full breaking change that would require a 2.0 release of Tokio.