sync: don't read target tree after reprojectcmd

After repo.reprojectcmd exits 0, _Reproject ran `git diff-index --cached
--name-only <revid>^{tree}` to verify that the index matches the target
commit's tree.

Peeling <revid>^{tree} and comparing every entry against the index
forces Git to read the target commit and walk every tree object in the
target revision from .git/objects.

reprojectcmd exists for virtualized filesystems such as ABFS whose
checkout command materializes the worktree and writes .git/index from
its own tree metadata without reading .git/objects/pack/*-trees-*.pack.
Running diff-index against <revid>^{tree} afterward forces Git to fault
in the tree packfiles over the network (260 FetchTrees pack downloads /
1.64 GiB across a 3,296-project Android checkout).

Trust reprojectcmd's exit status for index materialization instead of
re-walking the target tree in Git, while keeping the HEAD postcondition
check that verifies the command did not modify refs.

Bug: 543101585
Change-Id: Ie5feea41a4191245232c6763a489d01596370c55

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

docs/reproject-cmd.md

@@ -91,8 +91,9 @@ Detecting collisions with untracked files or unstaged working-tree modifications
 After the command exits with status 0, `repo` expects the following
 postconditions to be met:
 
-1.  `git diff-index --quiet --cached REPO_TREV^{tree}` exits 0 (the index
-    matches the target tree).
+1.  The index matches `REPO_TREV`'s tree (`repo` trusts the command's exit
+    status and does not run `git diff-index` against `REPO_TREV^{tree}`, which
+    would read every tree object from `.git/objects`).
 2.  `HEAD` still names what it did before the command, and its resolved commit
     object ID has not changed.