[simonchrz]

Every request for a General registry tarball with a hash other than the one behind the current name map started a goroutine. That goroutine downloaded the whole registry again from upstream instead of using the copy just cached. Nothing limited how many of these loads ran at once, and they had no deadline. Alternating requests between two valid snapshots therefore cost a full download and parse each time, and the map ended up at whichever snapshot was requested last, older ones included.

What changes:

• The name map is only reloaded for the hash /registries currently lists. /registries is read through the metadata cache that already serves it to clients. Older snapshots are still served, but they no longer trigger a download or replace the map.
• One reload runs at a time. A request that finds a reload running skips its own instead of waiting.
• The reload uses the request's context without its cancellation and stops after five minutes.
• Registry.toml is read up to 64 MB.

Tests cover old snapshots not being downloaded or rolling back the map, the current one loading once, skipping while a load runs, and the size limit.

[andrew]

Two follow-ups:

• The new tests all call refreshNamesFromRegistry directly, and nothing covers handleRegistry. A test that requests an old snapshot and then the advertised one through GET /registry/{uuid}/{hash}, and checks the name map and download counts (polling for the goroutine), would cover the path clients hit.
• loadRegistryTarball still downloads the tarball from upstream right after handleRegistry cached it, so each new General snapshot costs two full upstream downloads. Reading Registry.toml from the cached artifact would drop the second one.