Add support for compio async runtime

[vfosnar]

I have found these related issues/pull requests

Could relate to the migration from async-std to smol

Description

A better maintained thread-per-core runtime, alternative to monoio, that supports both Linux and Windows.

Source: https://github.com/compio-rs/compio

Prefered solution

Consider implementing it

Is this a breaking change? Why or why not?

Probably not

[abonander]

Supporting a completion-based runtime would be a significant refactor as all the buffered reads and writes are based around polling. I can imagine how it might look, but that's more work than I'm interested in doing anytime soon.

compio is not even at 1.0 yet, and even at a quick glance there's a number of design decisions I find questionable:

• the inclusion of a number of very heavyweight optional dependencies in the main crate can cause significant pollution of a project's Cargo.lock which a lot of users might complain about--something we learned about the hard way;
• both TLS and QUIC being part of the main crate suggests a weird ordering of priorities and prevents those APIs from evolving independently;
• in that same vein, including so many other crates in the public API is a huge SemVer hazard, especially ones that are explicitly still experimental like h3;
• a lot of APIs have at most one sentence for documentation, if they have any documentation at all;
• I can't for the life of me figure out how Dispatcher is meant to be used. It seems like an analogue of tokio::task::JoinSet, but the fact that panics on worker threads can entirely stall it, and that there's no way to spawn a blocking task when the dispatcher is at capacity without busy-waiting, suggests that it maybe needs another design pass or two. It also seems rather redundant since the runtime itself has the normal spawn() and spawn_blocking() methods that don't have these limitations.
• there's a comprehensive benchmark suite, but I would like to see some actual data from it without having to run it myself.

I can imagine a lot of this would get resolved over time as development continues, but it's also pretty clear that it's just not mature enough to depend upon yet for production software.

I'm also not convinced yet that io-uring is sufficiently faster or more efficient than epoll to justify the switch. Most of the hard data I can find on it is several years out of date, and it seems to depend heavily on the specific workload.