Use std IoVec types in AsyncRead and AsyncWrite

[withoutboats]

This issue is to track using the std IoVec types in our public API, instead of having the iovec crate as a public dependency. Currently these types are not in std, but they will be when rust-lang/rust#58357 lands. We'll have to decide when to make this shift: when they're available in nightly, or when they're available in stable.

[Matthias247]

How about no-std support? AsyncRead/Write traits are so universal that it would be very nice to have them available on those environments.

IoVec seems to be one more type which isn't available in that environment and moves us away from that goal. A generic &[&[u8]] parameter might be nicer. Which can be either directly cast to a OS specific IoVec on some platforms, or must be copied into another vector in the implementation. In the bad case, the copy (of e.g. 64 ptr/length tuples) is not that expensive compared to the overall cost of that huge IO operation.

[withoutboats]

I don't believe futures-io is intended to be no-std compatible any more than std::io is intended to be. The no-std ecosystem should develop its own abstractions appropriate to the kinds of guarantees that can be made about certain no-std environments. My understanding of futures-io is that it is modeled after std::io but async, and that it assumes a std-supporting platform.

[Nemo157]

The no-std ecosystem should develop its own abstractions

I really don't think we should have a split ecosystem at this level, io::{Read,Write} work fine as abstractions on no_std devices in a lot of (probably even the majority of) cases. The main issue is io::Error, but that is something that is already being tracked by the portability WG.

I don't believe futures-io is intended to be no-std compatible any more than std::io is intended to be.

This I agree with though. As long as futures-io doesn't force more use of std than already exists in std::io then it should be able to start supporting no_std at the same time. To that end, if std::io is introducing a dependency on some platform specific IoVec type, then that will have to be sorted out if std::io abstractions are to be used on no_std, so futures-io also using this type shouldn't make the transition any harder.