Use std IoVec on AsyncRead/AsyncWrite

[taiki-e]

By using this at an early stage, I think there is a high possibility of getting more tests and feedback early. I think that will have a positive impact on std IoVec API improvements and stabilization.

(Personally, at the time of stabilizing std IoVec API, it is preferable we are somewhat used to this API.)

Closes #1455

[seanmonstar]

Not to say that I'm against this, but just to call out explicitly: it's possible this could have these traits (and by extension all of futures-util) stuck on nightly longer, depending on if futures stabilize much sooner.

[taiki-e]

Yeah, I think the concern is right.

Current futures-util relies on the following unstable features:

#![feature(futures_api)]
#![cfg_attr(feature = "std", feature(async_await, await_macro, box_into_pin))]

I think futures_api in which the stabilization RFC is merged, and box_into_pin is likely to stabilize earlier than iovec. On the other hand, async_await and await_macro still have many blockers and unsolved problems, and I think stabilization of these features is likely to be slower than iovec, so I opened this PR.

(This is my personal thinking (I'm not participating in the WG discussions), so it may not be correct.)

[taiki-e]

Also, if a decision is made to close this PR to reduce uncertainty in the future, I will favor it.

[Nemo157]

On the other hand, async_await and await_macro still have many blockers and unsolved problems, and I think stabilization of these features is likely to be slower than iovec

Depending on stabilisation timing I’m pretty sure these parts of futures can be placed behind feature flags to allow moving the main part of the crate to stable.

Since there are default implementations of the vectored IO methods it seems like that could be possible for iovec as well.

[cramertj]

I agree with all the above comments-- I think this is a good direction to move, but I'd cfg-out the methods for now unless both the unstable feature is enabled, and avoid using iovec otherwise.