SG handling for mutations deduplicated by Couchbase feed

[adamcfraser]

Both TAP and DCP include the ability to deduplicate mutations by DocID. The result is that Sync Gateway may not see a sequence for an interim mutation.

This won't result in any data loss from Sync Gateway's perspective, but it can result in delays in the Sync Gateway _changes feed, while it waits for the sequence from the deduped mutation.

In SG 1.0.4 and earlier, rapid mutations to a single doc have the potential for introducing significant latency into the _changes feed. Post-1.0.4 this is mitigated by the the fix for #525, which makes missing sequences non-blocking.

However, there is still processing and performance overhead in Sync Gateway for the deduped sequences - they keep the 'low' sequence number unnecessarily low until they are eventually abandoned, and there's overhead when we eventually prune the sequence.

A possible immediate-term approach would be to store the sequence number history in the _sync/history along with the revision number history, and use that to identify any sequences that didn't appear on the TAP feed. This increases the size of the _sync metadata, but is relatively small compared to the other revision-level metadata we already store.

Longer term, this would overlap with the discussion about using vbucket-striped sequences for change tracking.

[adamcfraser]

Potentially "enhance" Walrus to reproduce this issue for unit test purposes.