Cluster configuration merge protection

[vazois]

This PR improves the merge config implementation to make it more robust in the presence of multiple back-to-back migration operations. It contains the following.

• Updated merge config implementation which separates merging of the worker metadata and the slotMap information. Currently, the slotMap at the receive node will only consider the slots owned by the sender node and update the ownership information only if the slot is in STABLE state, and the previous owner of the slot has a lower config epoch.
• Added a test case that stresses config merge implementation.
• Improved MIGRATE SLOTS option by ensuring that the target node safely (under lock) receives the most updated config information while the slot exchange occurs. This way we avoid configuration divergence in the presence of config epoch collisions.

Description:
When a node receives a gossip message from a remote node it attempts to merge the incoming configuration to that of the local copy. This happens in two steps as follows:

1. The local node first updates the workers data structure (within the configuration object) which contains metadata for all known workers. This happens by either creating new worker information if that worker did not exist or updating the existing worker information if the configEpoch for that worker (from the perspective of the sender) is greater than the config epoch of the existing entry in its local copy.

2. The second step is to merge the slot-map information of the sender config. It does this by considering only those slots which according to the sender are in stable state, are claimed by the sender itself and for which the previous owner’s epoch (if there was a previous owner) is lesser than the sender’s (claimant’s) epoch.

The second step is very important because we don't want some node updating the slot map ownership for another node, especially during migration where slot exchange needs to be coordinated between the source and target nodes.