loading: add JULIA_PRECOMPILE_CACHE_KEY to cache file names

[IanButterworth]

Fixes #63268

Claude:

---

Narrow alternative to #63293. Cache file names are keyed on the active project path, so containers that share a depot but mount different projects at the same path (say /work) give incompatible caches the same name and overwrite each other: alternating loads recompile every time, and concurrent precompilation fails with "Required dependency ... failed to load from a cache file" or "Module ... is missing from the cache".

Change

• New JULIA_PRECOMPILE_CACHE_KEY: if set, its value is mixed into the cache file name on top of the existing inputs (project path, preferences, flags, cpu target, julia binary and sysimage). It adds uniqueness; it does not replace any of them. The LRU and cleanup are untouched. Documented in the manual.
• The pidfile path leaves the key out, as it already leaves out the project and preferences: the lock is per package, taken before the file name is known, and a waiter re-checks for a usable cache once it gets the lock. Apps with different keys but the same package version therefore compile it once and share the result rather than twice in parallel.

What it does and does not do

• Loading reads file contents rather than names. A compatible cache written under one key is reused under any other, and changing the key does not trigger recompilation; it only affects which file a compile writes.
• Nothing changes unless the variable is set. Container runners give each app a stable, distinct key; apps with the same key and project path still collide, as before.
• This does not fix every shared-depot collision, only the same-path one the reporter hit.

Tests

In test/precompile.jl, using the key to stand in for separate apps: incompatible versions at one project path written under different keys coexist with their dependents and are reused when alternating (fails on nightly: the second write overwrites the first); a compatible cache is reused under another key without a new file; a rebuild under the same key and project replaces the same file; projects with different preferences keep separate files; unset/empty/set semantics and pidfile independence. precompile and loading test files pass locally. The two-container case itself was not run; it needs Linux mount namespaces.

[DilumAluthge]

The hostname is mixed into the cache file name

How would this work on an HPC cluster with multiple head nodes and multiple compute nodes, but a single filesystem mounted across all nodes?

[IanButterworth]

The first one to precompile it would give it a name based on those keys, then the others would use it.

The filename doesn't restrict cache usage.

[IanButterworth]

I guess a worry with this is that the hostname could be too volatile especially on laptops as it can be dependent on network characteristics, which would make a single project use up more cache slots.

[IanButterworth]

@KristofferC I'm not sure if there's a cleaner fix we can backport without adding an env var, perhaps this is acceptable?

[vtjnash]

This feels like it should be rewritten by a human. It currently seems to assume you are a robot who has read exactly how loading.jl is implemented.

[IanButterworth]

Happy to polish this if the approach sounds ok?

[vtjnash]

The approach seems a bit bad, but I'm not sure what else you'd do. It doesn't hurt anything, just an extra 200 lines of code (mostly tests)

[IanButterworth]

I think these might be a better approach #63310 JuliaLang/Pkg.jl#4824