io: add tokio_util::io::simplex

[ADD-SP]

Design document

https://gist.github.com/ADD-SP/7558ef3965f18ce1d721dff675d01d9b

Why not deprecate the tokio::io::simplex now?

Since the deprecation is not urgent, we can release this feature and first, and the deprecate the tokio::io::simplex after several months.

issue: #7548

[Darksonn]

mm. I'd like to avoid this dependence .... could we have Tokio expose no-op methods without rt?

[ADD-SP]

I will open another PR for this change.

I searched the internal usage of coop under the tokio crate, there are many things are heavily using the cfg_coop and poll_proceed_and_make_progress. It is reasonable to expose an no-op method, and also writing a guide for downstream.

tokio/tokio/src/io/util/mod.rs

Lines 90 to 102 in eb99e47

	cfg_coop! {
	fn poll_proceed_and_make_progress(cx: &mut std::task::Context<'_>) -> std::task::Poll<()> {
	let coop = std::task::ready!(crate::task::coop::poll_proceed(cx));
	coop.made_progress();
	std::task::Poll::Ready(())
	}
	}
	cfg_not_coop! {
	fn poll_proceed_and_make_progress(_: &mut std::task::Context<'_>) -> std::task::Poll<()> {
	std::task::Poll::Ready(())
	}
	}

[ADD-SP]

I found an alternative to avoid this dependency.

tokio/tokio-util/src/util/mod.rs

Lines 10 to 29 in d7f6d20

	cfg_rt! {
	use std::task::{Context, Poll};
	use tokio::task::coop::poll_proceed;
	use futures_core::ready;
	#[cfg_attr(not(feature = "io"), allow(unused))]
	pub(crate) fn poll_proceed_and_make_progress(cx: &mut Context<'_>) -> Poll<()> {
	ready!(poll_proceed(cx)).made_progress();
	Poll::Ready(())
	}
	}
	cfg_not_rt! {
	use std::task::{Context, Poll};
	#[cfg_attr(not(feature = "io"), allow(unused))]
	pub(crate) fn poll_proceed_and_make_progress(_cx: &mut Context<'_>) -> Poll<()> {
	Poll::Ready(())
	}
	}

[ADD-SP]

could we have Tokio expose no-op methods without rt?

There’s a small problem if we expose a no-op method without rt. The behavior of tokio::task::coop::* would become a bit surprising, and we’d need to write more documentation to explain it.

Fortunately, I found the alternative above, so we don’t need to worry about this issue.

[martin-g]

Both the issue and the implementation (this PR) do not say anything about vectored writes (https://docs.rs/tokio/1.48.0/src/tokio/io/util/mem.rs.html#387-400)
Are they omitted intentionally ?