Send artifacts to the client while a cache miss is stored #596

On a cache miss the proxy stores the whole artifact before it sends the first byte. Clients with an idle timeout give up while a large artifact downloads:

• git-lfs after 30 seconds without data (lfs.activitytimeout), which matters for LFS objects with Cache Git LFS objects #595;
• pacman after 10 seconds, which led to 2ed0327.

Since 2ed0327 the fetch keeps running after the client leaves, and a retry joins it. So the artifact does get cached, but the first clone or install fails or has to go through several retries. It works only if the download fits within the client's retries. A download longer than artifact_timeout never gets cached, and the whole response, download included, also has to fit within write_timeout.

Proposal: on a miss, send the bytes to the client while they are written to storage, with the hash computed along the way. StreamArtifacts already sends without storing.

• If the hash or declared integrity doesn't match at the end, the stored copy is discarded and the client's chunked response is left unterminated, so the client rejects it. This is how StreamArtifacts already handles a mismatch.
• Requests that join the same fetch keep waiting for the stored artifact as now. Letting them read the growing file could follow.
• Scanners in block mode need the whole file before anything is served, so with those configured a miss stays as it is now.
• If the client disconnects, the download keeps going, as it does today for detached fetches.

Open question: should this be the default for every ecosystem, or opt-in or per ecosystem? Package archives are mostly small, and the benefit is mainly for LFS objects, container layers and large packages.