Mark snapshot repository as corrupted if its UUID changes underneath us

[DaveCTurner]

Today if Elasticsearch observes a change in repository UUID it will accept the new UUID without question. IIRC this leniency dates back to the introduction of repository UUIDs in 7.x. However these days there should be no need for this leniency, and indeed if we see a repository UUID that differs from the one recorded in the cluster state then this indicates that something has changed the repository contents underneath us. With searchable snapshots, this is almost certainly a bad situation to be in. I think we should treat this situation similarly to how we react to seeing the RepositoryData generation change: apply the corruption marker and block further operations until the repository is explicitly re-registered.

[elasticsearchmachine]

Pinging @elastic/es-distributed (Team:Distributed)