This commit implements the HTTP registry API from
rust-lang/rfcs#2789.

A proof-of-concept server implementation exists at
https://github.com/kornelski/cargo-static-registry-rfc-proof-of-concept

The client implementation supports the changelog extension in the RFC,
but the server does not at the time of writing.

This first draft does not take advantage of `Etag` to avoid
re-downloads if the server does not support changelog. It also does not
download multiple index files concurrently, since the Registry trait
doesn't lend itself well to that at the moment.

With this change, a registry that does not support the optional
changelog feature will no longer purge the index on every build.
Instead, it will double-check the current file contents with the server
for each load, which is fairly efficient if a given index file has _not_
changed. The changelog is (unsurprisingly) still much more efficient.

They're handled the same anyway.

This doesn't quite work yet. Something needs to call `prefetch`, and
there's still an important TODO about making sure calls to `load` do not
re-fetch files that have already been prefetched.

Since we now also have to collect the `deps` iterator, we have it
implemented `ExactSizeIterator` to avoid excessive allocations.

This is kind of unfortunate since it talks about prefetching even for
sources that do not support it. The reason for this is that we have to
load the source before we can even check whether it supports
prefetching, and for these tests what fails is loading the source...

It's not really necessary. It's okay if it takes us slightly longer to
generate an error.

Note that this could be a decent amount nicer with
dtolnay/semver#170

This currently ends up in some kind of loop for cargo-like deps:

    yielding already-fetched rustversion
    yielding already-fetched futures
    yielding already-fetched thiserror
    yielding already-fetched anyhow
    yielding already-fetched rustversion
    yielding already-fetched futures
    yielding already-fetched thiserror

Everything _up_ to that point terminates pretty quickly.

It's not _super_ helpful at the moment since the number keeps
fluctuating...

This allows us to start downloads of a tonne of index files we otherwise
would not discover until much later, which saves us many RTTs. On a
dependency graph like that of cargo itself, it cut my download time to
1/5th.

This will be needed for the new sparse registry to allow it to keep
track of files it has already checked with the server.

It does jump a bit, but it's better than what was.

Thanks @Nemo157

The index yields versions in chronological order, but 0.2.7 can still be
released as a hotfix release after 0.3.0 was released. Similarly, we may
depend on something like 1.0 _and_ 2.0 of a crate through different
dependency paths. _Maybe_ there's an optimization in there somewhere,
but it's not as simple as this.

See rust-lang/rfcs#2789 (comment)

This also re-enables the requirement of -Z http-registry