Inconsistent GetCurrentTopology() payload

In a recent CBSE, a customer had an undersized cluster and was attempting to add a node so that all partitions could be accommodated. 

The rebalance kept get cancelled with a badmatch error reported by ns_server since the payload in GetCurrentTopology() changed without a corresponding revision number change.

This occurred since the FTS process' response to GetCurrentTopology() returned a warning about the undersized cluster but reset the warning on the next PrepareTopologyChange(), leading to the mismatch.

It was also observed that the warnings persisted in metakv did not change despite there now being sufficient nodes in the cluster and since these warnings are used to populate the GetCurrentTopology() payload on process start, they ought to be consistent.