[Distributed Index] Fix for update_seq and committed_update_seq in /db/, when using vector clock sequences

[tleyden]

This came out of https://github.com/couchbase/sync_gateway/issues/1159#issuecomment-142731185

It appears that the /db/ endpoint is returning the wrong values for the update_seq and committed_update_seq fields.

[adamcfraser]

This is primarily around supporting the standard Couch DB /db endpoint, which defines update_seq and committed_update_seq as:

committed_update_seq The number of committed updates. update_seq The current number of updates made in the database.

We were previously using the high global integer sequence for both of these.

When using a vector clock sequence and index bucket, I propose we change this to the sum of the vb sequence numbers in the index's stable clock. This represents the total number of updates that have been seen by Couchbase Server and indexed by Sync Gateway (i.e. are available for retrieval)

The downside is that this value isn't a valid doc sequence number (i.e. it can't be used as a since value) - it's just a count. Unfortunately, since Couch DB defines these values as integer, we don't have the option of returning the hash of the stable sequence.

This value isn't used during CBL replication, so there shouldn't be any impact there.

@snej - do you have any input on whether there's a need to return committed_update_seq and update_seq on the /db/ endpoint as something more than just a count?

[tleyden]

I'd recommend that we just use a string sequence number, as is done in Cloudant:

http://stackoverflow.com/questions/20446673/update-sequence-changed-semantics-in-cloudant-db

[adamcfraser]

Closing since there aren't any known usages of this field in the sg_accel scenario. Will reopen if there's a valid use case raised.