Changing --remote_instance_name should invalidate cached digests

[tpudlik]

Description of the bug:

In incremental builds, Bazel assumes any digest found to be valid in a previous execution will remain valid for a period of time. In particular, this is true even across invocations with --remote_instance_name set to different values. But if you're switching to a new remote instance, its contents will of course be different, so all cache digests ought to be invalidated. Otherwise, incremental builds with fail with spurious SPAWN(REMOTE_CACHE_EVICTED) errors.

The same may apply to some other flags that control which cache instance Bazel communicates with, like --remote_cache.

Which category does this issue belong to?

Remote Execution

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

No response

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

For Googlers: see b/369413203 for an instance of this bug "poisoning" CI bots.

[tpudlik]

@tjgq FYI

[layus]

Chiming in to add --disk_cache to the list of flags to be monitored.