Use tokio instead of async_std

[ljedrz]

We already use it in ipfs-http, our dependencies either already use it or are compatible with it and it has some nice features that we'd like to use.

Note: the async tests now specify max_threads = 1 in order to make sure the multi-threaded executor is not being lenient about any hidden bugs.

fixes #275

[koivunej]

TODO: soon tokio-mdns as well, mdns might still use async-std by default.

[ljedrz]

Good catch! I was looking at the main features in search for other tokio ones and found none - mdns does use async-std right now; probably gonna change soon, like you're saying.

[ljedrz]

it seems that the resolve tests don't like Windows; since this is a big PR and I wouldn't want to keep other PRs waiting I'll #[ignore] them again for now.

[koivunej]

The failure for future reference: https://github.com/rs-ipfs/rust-ipfs/runs/980815860#step:16:64

it seems that the resolve tests don't like Windows

Did you understand from somewhere else that this could be wider issue? Could be that windows is behind a restricted dns for example or just this particular runner was without global dns.

Note: the async tests now specify max_threads = 1 in order to make sure the multi-threaded executor is not being lenient about any hidden bugs.

From probably the first bad tests/ case I've hoped we could go back to tokio for single threaded test cases. Turns out a lot of the test cases have been just flaky/broken but this should stop us from writing any futures which are always ready for example, though it's been a while since I last wrote such. In multi threaded runtime those will be fine, but on single threaded runtime hopefully the runtime should grind to a halt but at minimum it should be noticeable.

[koivunej]

nice to have even smaller Cargo.lock

[koivunej]

I think windows is about to hang again.

bors r+

[bors]

Build succeeded:

• ci