Rollback is not triggered when some partitions get ahead of KV

As observed in CBSE-14484, some partitions in several datasets somehow are way ahead of KV- as the relevant logs have rolled over, I cannot determine how this happened, but when this occurs the problematic partitions will remain permanently ahead of KV, until such time that all vbuckets seqnos advance beyond the levels recorded in the partitions. This can result in wrong data being returned from queries, as well as will prevent any analytics rebalances.

We should validate the seqnos in all partitions at bucket connect time, and roll back any partitions which are ahead of KV.

In the CBSE-14484, this would've caused the problematic partitions to be corrected at the conclusion of the first failed rebalance, instead of the customer having to drop all of the problematic datasets, or remove the service from the cluster to remedy.