Bump tokio from 1.15.0 to 1.16.1

[dependabot]

Bumps tokio from 1.15.0 to 1.16.1.

Release notes

Sourced from tokio's releases.

Tokio v1.16.1

1.16.1 (January 28, 2022)

This release fixes a bug in #4428 with the change #4437.

#4428: tokio-rs/tokio#4428 #4437: tokio-rs/tokio#4437

Tokio v1.16.0

Fixes a soundness bug in io::Take (#4428). The unsoundness is exposed when leaking memory in the given AsyncRead implementation and then overwriting the supplied buffer:

impl AsyncRead for Buggy {
    fn poll_read(
        self: Pin<&mut Self>,
        cx: &mut Context<'_>,
        buf: &mut ReadBuf<'_>
    ) -> Poll<Result<()>> {
      let new_buf = vec![0; 5].leak();
      *buf = ReadBuf::new(new_buf);
      buf.put_slice(b"hello");
      Poll::Ready(Ok(()))
    }
}

Also, this release includes improvements to the multi-threaded scheduler that can increase throughput by up to 20% in some cases (#4383).

Fixed

• io: soundness don't expose uninitialized memory when using io::Take in edge case (#4428)
• fs: ensure File::write results in a write syscall when the runtime shuts down (#4316)
• process: drop pipe after child exits in wait_with_output (#4315)
• rt: improve error message when spawning a thread fails (#4398)
• rt: reduce false-positive thread wakups in the multi-threaded scheduler (#4383)
• sync: don't inherit Send from parking_lot::*Guard (#4359)

Added

• net: TcpSocket::linger() and set_linger() (#4324)
• net: impl UnwindSafe for socket types (#4384)
• rt: impl UnwindSafe for JoinHandle (#4418)
• sync: watch::Receiver::has_changed() (#4342)
• sync: oneshot::Receiver::blocking_recv() (#4334)
• sync: RwLock blocking operations (#4425)

Unstable

... (truncated)

Commits

• 91b9850 chore: prepare Tokio v1.16.1 release (#4438)
• 3c46705 io: fix take pointer check (#4437)
• afd2189 chore: prepare Tokio v1.16 release (#4431)
• 986b88b chore: update year in LICENSE files (#4429)
• 257053e util: add spawn_pinned (#3370)
• 5af9e0d sync: add blocking lock methods to RwLock (#4425)
• 8f77ee8 net: add generic trait to combine UnixListener and TcpListener (#4385)
• 2747043 tests: enable running wasm32-unknown-unknown tests (#4421)
• 2a5071f feat: implement Framed::map_codec (#4427)
• 621790e io: fix take when using evil reader (#4428)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[mre]

This one is supposed to contain a great perf boost (~20% in some benchmarks). However I don't think we'll see much change, because it is mostly an optimization for workloads where work distribution is not evenly spread out across all cores according to this comment:

If you are saturating all workers [...], then there would be no visible improvement as it only applies when only a few workers are actually kept busy.

Given the isolated nature of individual requests, lychee is capable of spreading the load across all cores quite evenly. The only situation I can think of where the distribution is not even would be at the start where we extract the links from the inputs, but in this scenario there's not much we can do other than streaming the extracted links to the collector, which is currently not happening.