Terse bucket info revision must take quorum failovers into account.

Currently the revision that ns_server exposes via CCCP and /pools/default/b/<bucket name> is computed as the sum of the number of ns_config changes and the highest seqno from chronicle. Clients use this revision to select the "most up-to-date" configuration to use. Due to quorum failover some clients might hence get stuck on the configuration from the failed over part of the cluster (due to a higher revision number).

One simple way to handle this is to include the number of quorum faliovers the node has seen into the revision calculation. Something like (NumQuorumFailovers << 48) + NumNsConfigChanges + ChronicleSeqno.

This doesn't handle scenarios where both partitions fail each other over. But since that requires user's participation and is not something we claim to support well, it should probably be good enough.

There's another consideration having to do with the fact that json parsers differ in their support for large numbers. For that reason the exact shift to be used for the number of quorum failovers needs to be decided upon carefully.