Changes to Root-Level index-N (RepositoryData)

This change adds a new field "shards" to RepositoryData that contains a mapping of IndexId to a String[]. This string array can be accessed by shard id to get the generation of a shard's shard folder (i.e. the N in the name of the currently valid /indices/${indexId}/${shardId}/index-${N} for the shard in question).

Benefits

This allows for creating a new snapshot in the shard without doing any LIST operations on the shard's folder. In the case of AWS S3, this saves about 1/3 of the cost for updating an empty shard (see #45736) and removes one out of two remaining potential issues with eventually consistent blob stores (see #38941 ... now only the root index-${N} is determined by listing).

Also and equally if not more important, a number of possible failure modes on eventually consistent blob stores like AWS S3 are eliminated by moving all delete operations to the master node and moving from incremental naming of shard level index-N to uuid suffixes for these blobs.

Only Master Deletes Blobs

This change moves the deleting of the previous shard level index-${uuid} blob to the master node instead of the data node allowing for a safe and consistent update of the shard's generation in the RepositoryData by first updating RepositoryData and then deleting the now unreferenced index-${newUUID} blob.
No deletes are executed on the data nodes at all for any operation with this change.

Note also: Previous issues with hanging data nodes interfering with master nodes are completely impossible, even on S3 (see next section for details).

Why Move from index-${N} to index-${uuid} at the Shard Level

This change changes the naming of the shard level index-${N} blobs to a uuid suffix index-${UUID}. The reason for this is the fact that writing a new shard-level index- generation blob is not atomic anymore in its effect. Not only does the blob have to be written to have an effect, it must also be referenced by the root level index-N (RepositoryData) to become an effective part of the snapshot repository.
This leads to a problem if we were to use incrementing names like we did before. If a blob index-${N+1} is written but due to the node/network/cluster/... crashes the root level RepositoryData has not been updated then a future operation will determine the shard's generation to be N and try to write a new index-${N+1} to the already existing path. Updates like that are problematic on S3 for consistency reasons, but also create numerous issues when thinking about stuck data nodes.
Previously stuck data nodes that were tasked to write index-${N+1} but got stuck and tried to do so after some other node had already written index-${N+1} were prevented form doing so (except for on S3) by us not allowing overwrites for that blob and thus no corruption could occur.
Were we to continue using incrementing names, we could not do this. The stuck node scenario would either allow for overwriting the N+1 generation or force us to continue using a LIST operation to figure out the next N (which would make this change pointless).
With uuid naming and moving all deletes to master this becomes a non-issue. Data nodes write updated shard generation index-${uuid} and master makes those index-${uuid} part of the RepositoryData that it deems correct and cleans up all those index- that are unused.