Threaded FS IO probably should be async now?

Being able to use async where relevant across the codebase makes it possible to use async constructs where relevant. rustup has many places where that can be useful: downloading channel metadata, distribution content, unpacking that content to disk, are work that could usefully proceed in parallel - and async provides a good abstraction for that.

We already have a sophisticated disk IO layer that accomodates various OS latency-inducing behaviours, and adapting that to async without any regressions could be very interesting too - but for now, it co-exists nicely with an async core.
https://github.com/rust-lang/rustup/pull/3367

We are still using an async-unaware threadpool here, and it's known to produce problems (https://github.com/rust-lang/rustup/issues/3125):

https://github.com/rust-lang/rustup/blob/fa4ae320550847f3b14c20023b8b042c91c5cc3e/src/diskio/threaded.rs#L1-L6

Anyway, using RUSTUP_IO_THREADS=1 to limit concurrency feels a bit off. Will migrating to async help?

Start by reading src/diskio/threaded.rs and the discussion in issue #3125, then compare the async direction described in PR #3367. Done would require a decided migration scope and validation that the existing disk I/O behavior and concurrency controls remain correct.