Deprecate `async_std` support

[elenaf9]

Description

Moving this into a separate issue to increase awareness.

We are planning to deprecate support for async_std throughout all of rust-libp2p.
See prior discussion in #4449 (comment) and #3515 (comment).

If anyone still depends on it, please comment in this issue.

Depends on #4449.

Motivation

async-std has officially be discontinued and tokio has become the de-factor standard async runtime in the ecosystem.

Current Implementation

We currently support two runtimes, tokio and async_std. tokio is already the default in most examples/ tests.

Implementation-wise, this concerns the swarm, mDNS, and the transports TCP, QUIC and DNS.

Open Question

Copying from #3515 (comment):

We then have to make a decision on whether we will in the future only support tokio, or still want to be open to support other runtimes, e.g. smol that is recommended by async_std as alternative.
Right now we have in many transports, like tcp, a Provider abstraction for the different runtimes. If we'll only support tokio we could get rid of this abstraction, but under the risk of having to re-add it once there is a demand to an alternative to executor.

Are you planning to do it yourself in a pull request?

Maybe

[elenaf9]

Copying over @dariusc93 comment from #3515 (comment):

But I think we then have to make a decision on whether we will in the future only support tokio, or still want to be open to support other runtimes, e.g. smol that is recommended by async_std as alternative.

I would have to double check but we could an SmolExecutor if there is not one already and add it apart of SwarmBuilder, but I am all for just deprecating async-std without adding smol or additional executors as well (though others may have different opinions for that, which I am all for hearing)

Right now we have in many transports, like tcp, a Provider abstraction for the different runtimes. If we'll only support tokio we could get rid of this abstraction, but under the risk of having to re-add it once there is a demand to an alternative to executor.

Im all for of keeping the abstractions and supporting multiple runtimes, either what we would support in our protocols or by allowing the user to supply their own runtime, though we should probably continue to prefer tokio (or wasm-bindgen-futures for wasm32 arch) while still leaving the abstraction for others to bring their own runtime if needed. That way we can avoid re-adding the abstractions in the future unless we are dead-set on using tokio through and through, though we would never know for sure if something would replace tokio in the future.

[elenaf9]

Copying over @jxs comment from #3515 (comment):

But I think we then have to make a decision on whether we will in the future only support tokio, or still want to be open to support other runtimes, e.g. smol that is recommended by async_std as alternative.

Thanks for bringing this Elena, yeah we probably need to address it.

Right now we have in many transports, like tcp, a Provider abstraction for the different runtimes. If we'll only support tokio we could get rid of this abstraction, but under the risk of having to re-add it once there is a demand to an alternative to executor.

true but tbh it seems the days of new runtimes are over, tokio has now become the de facto runtime right? smol has 300k downloads per month, tokio has 13 million

IMHO we'd just remove async-std code and stick to tokio, if anyone needs smol for a particular transport they can have and maintain a fork on their own repos, we can link to if if needed wdyt?
But is there anyone still using async-std?
cc @lyzkov since you were the only one commenting on #4449 (comment).

[dariusc93]

IMHO we'd just remove async-std code and stick to tokio, if anyone needs smol for a particular transport they can have and maintain a fork on their own repos, we can link to if if needed wdyt?
But is there anyone still using async-std?

So that means we would remove the abstractions that support different runtimes, or would we keep those in place?

[drHuangMHT]

I would like to keep the abstraction layer to make it easier for users who wants to make an adapter, but not very strongly. Rust has zero-cost abstractions right? There won't be additional cost in runtime with no dynamic dispatch, but silghtly more code for us to maintain.
If what we really want is to simply reduce dependency tree, just remove async_std and keep the abstractions. But if we also want to maintain less code, remove the abstractions as well.
EDIT: I personally have never used async_std or smol so no feelings about them.

[dariusc93]

I would like to keep the abstraction layer to make it easier for users who wants to make an adapter, but not very strongly. Rust has zero-cost abstractions right? There won't be additional cost in runtime with no dynamic dispatch, but silghtly more code for us to maintain. If what we really want is to simply reduce dependency tree, just remove async_std and keep the abstractions. But if we also want to maintain less code, remove the abstractions as well. EDIT: I personally have never used async_std or smol so no feelings about them.

Personally for me, i think keeping the abstraction layer would not add any cost and would make it easier for others to implement other runtimes vs forking libp2p and/or the protocols (or utils) and adding it.

[jxs]

yeah it's decided then, you win 😛
Let's leave the abstractions with comments on the why they are still there

[gitToki]

@elenaf9 Could I take this issue :) ?

[elenaf9]

@elenaf9 Could I take this issue :) ?

@gitToki yes, thank you!
Would be great to have a separate PR per crate that is affected, makes it easier to review.