Don't share caches between different jobs by default

[TimJentzsch]

Consider this scenario:

You have one job which runs cargo test and one which runs cargo check.
These jobs will need separate compilations, as they run with different profiles.

Right now it can happen that they share a cache: Maybe cargo check runs first and then cargo test cannot find a cache, but _falls backto the cache generated bycargo check`.

This can bloat the cache size, as now the target folder is filled with both.
This problem can accumulate as the cache is never cleaned up.

A quick solution would be to remove the last cache key fallback which does not depend on the job ID. Then, the cargo check and cargo test jobs would never share a cache.

This issue has been discovered via TheBevyFlock/bevy_quickstart#212

[benfrankel]

I actually wonder if it would be best to fully remove cache fallbacks (if it's not possible to prune the target/ directory automatically). Even if it's just the Cargo.toml file changing multiple times, it could cause cache size ballooning with unused dependencies / versions getting pulled into the new cache, though maybe not as rapidly as fallbacks between different jobs.

Needs some testing and consideration of the tradeoffs to decide, though.

[TimJentzsch]

Hmm, definitely needs some testing. Compiling without a cache is definitely taking a long time, but maybe it's worth the saved storage space?

[benfrankel]

For some anecdotal data: My jam game just had a failed CI due to the runner running out of storage space. I checked and my caches were all ~3.2GB each. I deleted the saved caches and re-ran the same CI workflow, and the new caches were ~400MB, 400MB, and 1.2GB.