CBL-7841: Handle conflict when revision history appears broken

This is a fallback for cases where the general comparison algorithm
yields a Conflict while applying a remote revision to the local
document. The target scenario is a deleted document being resurrected
in CBS -- when that happens, the resurrected document has no history
prior to the deletion.

Author: jianminzhao

LiteCore/Database/VectorDocument.cc

@@ -428,6 +428,58 @@ namespace litecore {
             } else {
                 // Compare it with the current document revision:
                 order = VersionVecWithLegacy::compare(newVers, curVers);
+
+                // CBL-8277: Handle the case where revision history may appear broken.
+                //
+                // Concrete scenario for a single document ID:
+                //   1. Local DB deletes the doc.
+                //   2. Local pushes the tombstone to a remote SGW.
+                //   3. In the target CB database, a new doc is created with the same ID.
+                //      (In CBS, a deleted doc is effectively purged, so the ID is free
+                //      for reuse by an unrelated document.)
+                //   4. Local DB performs a pull.
+                //
+                // At step 4 the BLIP message carries a document that starts at a new
+                // version with no history. In general, this conflicts with whatever
+                // revision Local currently holds, and it is indistinguishable from a
+                // genuinely new document authored elsewhere (i.e. one that never went
+                // through the sequence above). The following analysis shows how we can
+                // recognize the sequence above and treat `newVers` as a newer revision
+                // rather than a conflict.
+                //
+                // Proposition:
+                //   For a given document at a given remote, the set of authors in the
+                //   Version Vector may only grow.
+                //
+                // Applying the proposition here:
+                //   - `remote`  : the remote index that `newVers` came from.
+                //   - `rev`     : the latest revision we know we have shared with remote
+                //                 `remote`.
+                //   - `newVers` : the revision arriving from `remote` via BLIP.
+                //
+                // Because the remote has already seen `rev`, its Version Vector must
+                // contain `rev`'s author. Our general VV comparison relies on this. If
+                // that author is now missing from `newVers`, it must have been dropped.
+                // From this we can draw the following conservative conclusion:
+                //
+                //   `newVers` is "newer" than any version that shares an author with
+                //   `rev` at the same or older age (lower or equal logical clock).
+                //
+                // In general, we further posit that is_newwer_or_same is transitive.
+                // From the fact that `rev` has been seen by the remote,
+                //  `newVers` is_newer_or_same `rev`
+                // Therefore, we can deduce that `newVers` is_newer_or_same `curVers`
+                // if `rev` is_newer_same `curVers`. Since `same` can be determined by the
+                // general comparison, we are only concerned here with is_newer.
+
+                if ( order == kConflicting && remote != RemoteID::Local ) {
+                    if ( optional<Revision> rev = _doc.loadRemoteRevision(remote); rev ) {
+                        VersionVecWithLegacy landmark{rev->revID};
+                        versionOrder         orderWithLandmark = VersionVecWithLegacy::compare(landmark, curVers);
+                        if ( orderWithLandmark == kSame || orderWithLandmark == kNewer ) order = kNewer;
+                    }
+                }
+
                 logPutExisting(curVers, newVers, order, remote);
 
                 // Check for no-op or conflict: