Support zipzstd cache compression format

Rafael Fonsecarequested to merge
rafael.fonseca1/gitlab-runner:more_cache_improvements into main

What does this MR do?

Maps CACHE_COMPRESSION_FORMAT=zipzstd to archive.ZipZstd in the cache archiver. Previously only tarzstd was special-cased and any other value (including zipzstd) silently fell back to zip (deflate), so the ZIP+Zstandard format was unreachable for caches even though the archiver already exists.

zipzstd compresses each file as an independent ZIP entry, so it archives in parallel and — with FF_USE_FASTZIP — extracts in parallel, at the cost of a slightly larger archive than tarzstd but still much smaller than the standard deflate. The extractor needs no change: openArchive already detects the ZIP container by magic bytes and, with FF_USE_FASTZIP, routes it to the fastzip extractor.

Also updates the cache-compression docs to list zipzstd.

Why was this MR needed?

The zipzstd (zip + zstd) archiver was added in !4107 (merged) and is the only cache format that compresses and decompresses in parallel (per-entry, via fastzip), but it was only ever wired up for artifacts, which can't actually use it until the server side issues are resolved to support it. For caches, CACHE_COMPRESSION_FORMAT recognized only tarzstd (added in !4807 (merged)); every other value fell through to zip (single-threaded deflate), so there was no way to select the parallel zstd format for a cache.

tarzstd gives a better compression ratio, but it is a single serial zstd stream — both compression and decompression are effectively single-core. On multi-core runners with large caches, zipzstd is substantially faster to create and to extract because the work fans out across cores, for only a small size increase. This gives users a parallel option for large caches without changing the default (related to #39287).

What's the best way to test this MR?

  1. On a job with a cache, set: 
    variables:
  CACHE_COMPRESSION_FORMAT: zipzstd
  FF_USE_FASTZIP: "true"   # required for the parallel extractor

Confirm the produced cache archive is ZIP+zstd (starts with PK\x03\x04; entries use the zstd method) and that a downstream job restores it correctly. On a multi-core runner with a large cache, compare archive size and create/extract wall time across zip, tarzstd, and zipzstd. Run the existing cache archiver/extractor unit tests; a unit test asserting CACHE_COMPRESSION_FORMAT=zipzstd resolves to archive.ZipZstd guards against regression.

What are the relevant issue numbers?

There is no dedicated issue for exposing zipzstd to caches; this extends existing work and relates to the cache-performance discussion:

Related: #39287 (Parallel / multi-threaded cache uploads & downloads for large artifacts and caches) Builds on: !4807 (merged) (Enable tarzstd archive format for caches), !4107 (merged) (Added zip+zstd and tar+zstd archivers) Docs precedent: #38884 (closed) / !5673 (merged) (Document tarzstd as an argument for CACHE_COMPRESSION_FORMAT) Background: #25991 (closed) (Artifact / Cache Performance), #28989 (closed) (FF_USE_FASTZIP enablement)

Merge request reports