Upgrade async-std to 1.6.1

[secretfader]

Resolves #1588, and allows libp2p to be used in projects that rely on the latest version of async-std.

[mxinden]

Have the failures related to #1588 been addressed?

[secretfader]

@mxinden I'm not familiar with the issues encountered earlier in #1588. In fact, I hadn't seen that issue until now. My primary goal was to reconcile dependency versions of async-std with requirements of a project that uses libp2p.

If I understand correctly, the original issue was that CI broke with the update of async-std to 1.6.0.. Based on what I can see here, it seems all CI checks have passed except one.

[secretfader]

After re-reading #1588, I see the problem is with the Noise protocol smoke test, which I'll attempt to resolve here.

[secretfader]

@mxinden Tests are passing with async-std version 1.6.1, which should resolve #1588. The problem? Tests were assuming an available runtime to schedule async tasks against, but found none and stalled execution instead.

While including async-std everywhere async tests will need to run is an imperfect solution, but one I'm comfortable accepting temporarily (until we find a more ergonomic and performant method).

[tomaka]

It would be very unsettling if async-std now forced you to use their runtime for the sockets to work. This isn't mentioned in their CHANGELOG, and the main reason why we were using async-std in the first place is that you didn't have to do that.

@stjepang @dignifiedquire Sorry to ping you here, but could I ask you if it is an expected behaviour that sockets don't work if you don't use #[async_std::test]?

[dignifiedquire]

@tomaka @secretfader when you are saying you are not using the runtime, are you manually polling the sockets, or how exactly is the setup you are expecting to work?

[dignifiedquire]

if it is an expected behaviour that sockets don't work if you don't use #[async_std::test]

The goal is to have them work, when polling manually, independent of the runtime that is polling them. The current situation for TcpStream::connect is the following

• in 1.5 and earlier SocketAddrs were resolved using a manual implementation, which would only spawn a blocking task for resolution if it couldn't resolve them locally, see https://github.com/async-rs/async-std/blob/v1.5.0/src/net/addr.rs for details
• in 1.6 we use delegate the connection to smol::Async, which immediately spawns a blocking task, no matter of the input data: https://github.com/stjepang/smol/blob/master/src/async_io.rs#L661 so the behaviour is the same for cases where resolution needs to happen, but not where the resolution can be done locally.

This isn't mentioned in their CHANGELOG

Because I did not realize this behaviour had chaneged, and it was not my intention to bind the sockets to the runtime in this way. I am considering this a bug in the 1.6 releases, and effectively for the cases it is happening in 1.5 too. I am sorry for the troubles this is causing.

[dignifiedquire]

After speaking @stjepang I realized my analysis above was wrong. We need to ensure that the reactor is running when creating sockets, which is simply in bug in async-std atm. Going to attempt a fix and see if I can get libp2ps test working out of the box

[dignifiedquire]

Good news, I have a working fix for async-std, which I will be publishing once CI and review are done. This will allow you to upgrade without any other changes to the tests, as it was intended.