In general we need to do [ cluster change -> swap -> rebalance state
change ]
NOTE: The update of the cluster metadata and the rebalancer state is not
"atomic". Ergo, there could theoretically be a race where a client picks
up new cluster metadata sends a request based on that, but the proxy
bridges have not been setup and we either miss a proxy put or return a
null for get/getalls
TODO:refactor The rollback logic here is too convoluted. Specifically,
the independent updates to each key could be split up into their own
methods.

Parameters:

cluster - Cluster metadata to change

rebalanceTaskInfo - List of rebalance partitions info

swapRO - Boolean to indicate swapping of RO store

changeClusterAndStoresMetadata - Boolean to indicate a change of
cluster metadata

changeRebalanceState - Boolean to indicate a change in rebalance
state

rollback - Boolean to indicate that we are rolling back or not

rebalanceNode

This function is responsible for starting the actual async rebalance
operation. This is run if this node is the stealer node
We also assume that the check that this server is in rebalancing state
has been done at a higher level