sync: roll back repo when stable is rewound

The documented way to roll back a bad release is to force push an older
release to stable, and docs/release-process.md says clients will then
automatically downgrade. _PostRepoFetch already supports switching to an
older commit, but it only runs when `RepoProject.HasChanges` is true,
and that used the `MetaProject` check of whether the remote has commits
that HEAD lacks. After a rewind it doesn't, so clients that had already
upgraded stayed on the bad release.

Make `RepoProject.HasChanges` true whenever the remote revision differs
from HEAD, in either direction. `ManifestProject` keeps the forward-only
check so local manifest commits are still rebased rather than dropped.

Bug: 571204396
Change-Id: I248507f434d2552ce11a9afabe9a6335cb24ddbd
Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/640130
Reviewed-by: Gavin Mak <gavinmak@google.com>
Tested-by: Brian Gan <brgan@google.com>
Commit-Queue: Brian Gan <brgan@google.com>

project.py

@@ -5507,6 +5507,18 @@ class RepoProject(MetaProject):
         except OSError:
             return 0
 
+    @property
+    def HasChanges(self) -> bool:
+        """Does the remote revision differ from what is checked out?
+
+        Unlike MetaProject, this is also true when the remote moved backwards:
+        a release rollback force pushes an older release to stable, and users
+        who already upgraded have to move back to it too.
+        """
+        # Not passing all_refs makes GetRevisionId peel annotated tags (from
+        # e.g. --repo-rev=v2.50) to the commit that HEAD points at.
+        return self.GetRevisionId() != self.GetHeadRevisionId()
+
 
 class ManifestProject(MetaProject):
     """The MetaProject for manifests."""