nar-bridge/tvix-store: don't block HEAD for .narinfo on ingest

#430
Opened by flokli at 2024-12-29T13·55+00

Seen in the nixos.tvix.store deployment (fetch-through cache for cache.nixos.org):

If we see a HEAD request for a "new" (not-yet-ingested) store path, we currently block responding to a HEAD request until we successfully ingested the entire NAR into castore.

This causes suboptimal performance for clients having it configured, as Nix first does do a HEAD request for all new store paths to decide whether to build or substitute.

Instead of doing this, we should reply to HEAD requests for new store paths as soon as we retrieved the NARInfo from the backend, and queue the NAR ingestion to the background (with a limit).

Subsequent GET requests for these store paths should block on the background task having finished.

The NixHTTPPathInfoService should get a config option to switch behaviour, and we also need to distinguish between get() and has() on the PathInfoService trait level.