The problem/use-case that the feature addresses

With the new CLUSTER SHARDS command and the documentation, SHARD is now a first class citizen in Redis cluster. However, unlike NODES or SLOTS, there is currently no unique ID associated with a SHARD.

A SHARD ID would allow an external entity to

1. Directly reference a shard (no longer via the unwieldy slot ranges)
2. Easily check whether two nodes belong to the same shard, even when one of them or both are down permanently. Today, a FAILED node would be listed under an "empty" shard in the CLUSTER SHARDS output because there is no easy way to retain its relationship with the shard.

Description of the feature

1. Introduce a 40-byte string as the shard ID, which is generated in the same way as the node ID
2. Every node gets a new shard ID on its first startup and the ID gets persisted to the nodes.conf as the last field in the node record (or next to the hostname)
3. On restart, the node gets its shard ID back from its nodes.conf
4. The shard ID is broadcast to the cluster in the same way as the hostname via the gossip Ping extension
5. On CLUSTER REPLICATE, the replica node updates its shard ID to match its primary's
6. CLUSTER SHARDS is updated to output the shard ID as well (as the first field and before the slot range)
7. [optional] Since CLUSTER SLOTS is deprecated (in 7.0+), no change is expected
8. [optional] Ideally, CLUSTER NODES should be updated but then there is the backcompat risk so either we skip it or expose the shard ID under a new named config.
9. [optional] Introduce a new CLUSTER MYSHARDID (less appcompat risk) or amend CLUSTER MYID (more natural but more appcompat risk) to return the node's shard ID.
10. [optional] Should CLUSTER REPLICAS be amended as well?

Alternatives you've considered

Additional information

@madolson @zuiderkwast @yossigo