Various cache fixes

[DaanDeMeyer]

We have access to the config object in have_cache() and this argument is specifically intended to be used whenever we pass the default tools tree to have_cache(), so let's just do the check based on config.image in have_cache() itself.

[behrmann]

The first two look good to me, the third one I don't quite get, since it's mostly doing the same as have_cache with less logging interspersed. The only marked difference is that have_cache also looks at the manifest, which could maybe be optional with a switch or go into a separate function.

[DaanDeMeyer]

The first two look good to me, the third one I don't quite get, since it's mostly doing the same as have_cache with less logging interspersed. The only marked difference is that have_cache also looks at the manifest, which could maybe be optional with a switch or go into a separate function.

The thing is, by the time we call reuse_cache(), we've already called have_cache() and cleaned up if needed, so I think it makes more sense for reuse_cache() to behave based on the paths on disk and not check the manifest again.

[behrmann]

The thing is, by the time we call reuse_cache(), we've already called have_cache() and cleaned up if needed, so I think it makes more sense for reuse_cache() to behave based on the paths on disk and not check the manifest again.

I don't disagree with the reasoning not check the manifest again, my point was that there's a lot of common logic in have_cache and reuse_cache now, but that can be fixed later, since the same idioms appear elsewhere, too.