For cluster msgs, save the extensions support flag immediately during…

… MEET processing

    For backwards compatibility reasons, a node will wait until it receives
    a cluster message with the open source extensions flag before sending
    its own open source extensions. This leads to a delay in shard ID propogation
    that can corrupt nodes.conf with inaccurate shard IDs if a node is restarted
    before this can stabilize.
    This fixes most of that delay by immediately triggering the extensions-supported flag
    during the MEET processing, allowing the PONG reply to contain OSS extensions and
    to be marked as compatible by the sender.

Signed-off-by: Ben Totten <[email protected]>

src/cluster_legacy.c

@@ -2996,14 +2996,20 @@ int clusterProcessPacket(clusterLink *link) {
         /* Add this node if it is new for us and the msg type is MEET.
          * In this stage we don't try to add the node with the right
          * flags, replicaof pointer, and so forth, as this details will be
-         * resolved when we'll receive PONGs from the node. */
+         * resolved when we'll receive PONGs from the node. The exception 
+	 * to this is the flag that indicates extensions are supported, as 
+	 * we want to send extensions right away in the return PONG in order
+	 * to reduce the amount of time needed to stabilize the shard ID */
         if (!sender && type == CLUSTERMSG_TYPE_MEET) {
             clusterNode *node;
 
             node = createClusterNode(NULL, CLUSTER_NODE_HANDSHAKE);
             serverAssert(nodeIp2String(node->ip, link, hdr->myip) == C_OK);
             getClientPortFromClusterMsg(hdr, &node->tls_port, &node->tcp_port);
             node->cport = ntohs(hdr->cport);
+	    if (hdr->mflags[0] & CLUSTERMSG_FLAG0_EXT_DATA) {
+                 node->flags |= CLUSTER_NODE_EXTENSIONS_SUPPORTED;
+            } 
             clusterAddNode(node);
             clusterDoBeforeSleep(CLUSTER_TODO_SAVE_CONFIG);
         }