GitLab

The recent https://crrev.com/c/1981610 removed the logic to update
local bookmark GUIDs upon remote incremental sync updates, but
overlooked the issues in the browser-upgrade path: and old client would
indefinitely continue with local bookmark GUIDs that never got updated,
and yet during commits those arbitrary GUIDs could get uploaded because
PopulateFinalGuid() had been called, and in fact client tag hash does
represent the authoritative bookmark GUID.

The fix proposed here is to revert back to the logic prior to the
offending patch linked above, and in addition add extra precautions
when uploading changes, via the newly-introduced
SyncedBookmarkTracker::Entity::final_guid_matches().

Because it's hard to reason about the effect of bad data in the
affected version range, and since the protobuf field number was
recently introduced (with no branch-point in between),
BookmarkSpecifics is updated again to start using a clean proto field
number.

Change-Id: I52bc516c3074cff778e10b55652d74bf8fc44684
Bug: 978430
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2030768
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Reviewed-by: Mohamed Amir Yosef <mamir@chromium.org>
Cr-Commit-Position: refs/heads/master@{#736925}