Cache Semantics

Caches in the sense of the "modular build paths" efforts contain:

• spack package sources
• spack build results (incl. spack buildcache usable content)

Cache hierarchy:

• ESD releases shall feed a world-readable "release cache" (via EBRAINS harbor, i.e. our official OCI registry)
• Writable dedicated caches per merge request (i.e. something like source branch?) shall provide faster development iteration times.
  • This cache is to be deleted upon MR merge OR if a 7d (TDB) timeout triggers.
  • (These caches might live in some gitlab OCI registry if this enables easier handling of cache flushing.)
• Any number of additional read-only caches shall be usable.

(Side remark (maybe to be moved to some other issue): spack can read from filesystem and S3 cache locations for package sources, from filesystem and CI registries for buildcache items — however, (as of now) it does not support the use of proxies (not even tsocks/`LD_PRELOAD` stuff is working) → problematic for a general-purpose tool that shall support caches.)