Use shard-id of the master if the replica does not support shard-id

If there are nodes in the cluster that do not support shard-id, they
will gossip shard-id. From the perspective of nodes that support shard-id,
their shard-id is meaningless (since shard-id is randomly generated when
we create a node.)

Nodes that support shard-id will save the shard-id information in nodes.conf.
If the node is restarted according to nodes.conf, the server will report a
`corrupted cluster config file` error. Because auxShardIdSetter will reject
configurations with inconsistent master-replica shard-ids.

In this PR, when process the gossip, if sender is a replica and does not
support shard-id, set the shard_id to the shard_id of its master.

This fix redis#12761.

src/cluster_legacy.c

@@ -2596,11 +2596,16 @@ void clusterProcessPingExtensions(clusterMsg *hdr, clusterLink *link) {
         /* We know this will be valid since we validated it ahead of time */
         ext = getNextPingExt(ext);
     }
+
     /* If the node did not send us a hostname extension, assume
      * they don't have an announced hostname. Otherwise, we'll
      * set it now. */
     updateAnnouncedHostname(sender, ext_hostname);
     updateAnnouncedHumanNodename(sender, ext_humannodename);
+    /* If the node did not send us a shard-id extension, it means the sender does not
+     * support it, node->shard_id is randomly generated. If sender is a replica, set
+     * the shard_id to the shard_id of its master. Otherwise, we'll set it now. */
+    if (ext_shardid == NULL && sender->slaveof) ext_shardid = sender->slaveof->shard_id;
     updateShardId(sender, ext_shardid);
 }