refactor(network): use async for registry network operations

[arlosi]

What does this PR try to resolve?

The existing model for registry index operations uses Poll + block_until_ready to enable parallelism. This model is somewhat awkward to work with, especially when parallelism is desired. Using async simplifies creating and working with registries.

Convert registry methods taking &mut self to &self

In order to execute multiple futures in parallel (using FuturesUnordered or similar), there must be multiple active borrows. Many of the registry querying methods used &mut self, which prevents this.

Any mutations are now handled by using Cell / RefCell. Since the executor is single-threaded, the operations aren't actually happening in parallel, but when passing an .await point, a different future could begin executing. We must be careful now not to hold mut borrows on RefCells across await points, as it will cause a panic.

Convert methods returning Poll<_> to return Future<_> (async).

When we want to block (and we're not in an async context), the async call is wrapped with futures::executor::block_on. If this is attempted within an existing async executor, cargo will panic.

Remove all block_until_ready methods from all Source, RegistryData traits

For most of the sources, the contents of the block_until_ready function was moved into a a private update function that's called once before making any queries.

Add new HTTP async http_async module

Wraps cURL's Multi interface to provide an async interface for making HTTP requests through cURL.

Add async-trait crate

This is used to enable dynamic dispatch on traits that use async fn.

Error message output changes

Due to refactoring around removing block_until_ready, some error messages are changed, usually by having additional context information. This change makes the error messages more consistent between various code paths. I attempted to minimize the changes in this PR for ease of review. We may want to simplify the error messages (by removing one level of context) in a follow up.

Resolver

The resolver is the only portion still using the Poll approach. An adapter layer in RegistryQueryer is added that immediately translates it into async.

Converting the resolver be async native is left as future work. In theory this conversion could provide performance improvements, since the resolution would not need to be restarted. It would also let the resolver start working immediately as new dependencies became available.

.crate downloading

The downloading of crate files using PackageSet is not yet converted to async. This is expected to be straightforward to do in a separate PR.

Progress reporting

The http_remote no longer has the ability to track how many block_until_ready calls have been made, so we can't do the trick where we assume we need 10 of them. The approach here is changed so the progress bar is completed/ (completed + pending). This means the progress bar can jump backwards.

How to review

Commit by commit. The final commit contains the majority of the change that was not straightforward to separate out.

[weihanglo]

Impressive. Net -20 LoC changes!

[arlosi]

@rustbot ready

I've split the PR into several commits. The last one is still large, but it's about 1/2 the size.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[arlosi]

I've split the commits up further, though the last commit is still pretty large.

A few of the very small ones could probably go in their own PR independent of this one.

The commits that add functionality could go in their own PRs, but nothing would use them until later - such as the async http client.

[rustbot]

☔ The latest upstream changes (possibly #16763) made this pull request unmergeable. Please resolve the merge conflicts.