MaxDeletedRevSeqNo may not be up-to-date on disk

MaxDeletedRevSeqno is updated in memory in the following case:

• Item is deleted
• Item is expired
• Item is evicted from hash table (in full-eviction mode) (HashTable::unlocked_ejectItem).

But this is saved to disk only when there is deleted item during flush. In two scenarios this could cause an inconsistency on-disk between the recorded maxDeletedRevSeqno and the actual highest rev seqno:

1. If maxDeletedRevSeqno was updated during eviction, then if there is a non-CAS Set on an evicted item, MaxDeletedRevSeqno will not be saved since this is only a SET op - see flushvBucket:

   357	// Track the lowest seqno, so we can set the HLC epoch
   358	minSeqno = std::min(minSeqno, (uint64_t)item->getBySeqno());
   359	vbstate.maxCas = std::max(vbstate.maxCas, item->getCas());
   360	if (item->isDeleted()) {
   361	vbstate.maxDeletedSeqno =
   362	std::max(uint64_t(vbstate.maxDeletedSeqno), item->getRevSeqno());
   363	}

2. For the same key, if there is a Add following a Delete, then it is possible that the Delete ops will be de-duped. So during flush, MaxDeletedRevSeqno will also not be saved since the flusher will not see the Delete op.

If immediately following (1) or (2) memcached crashed; then the on-disk maxDeletedRevSeqno would be inconsistent with the actual data (i.e. it would lag behind the actual maximum deleted revId).

Having said all that; the next delete (to any key) would result in maxDeletedRevSeqno getting persisted, so the possible window for this problem is small.