objectpool: Do not verify commit graphs when disconnecting alternates

When disconnecting the alternates file from a repository belonging to a pool, then we need to make sure that all required objects are in the repo before we remove the link to the pool. To do so, we first hardlink all objects from the pool repo into the pool member. Given that this has the potential for races which would leave the pool member in a corrupted state when removing the alternates file, we do a connectivity check after it was unlinked such that we can fail the RPC and move back the link in case the check fails.

This connectivity check has started to fail on Git's next branch with an error message complaining about commits being inconsistent in our commit graph. This inconsistent commit-graph entry refers to a commit which indeed has an invalid date, and because the commit-graph fixes up commit dates to be sane this leads to an inconsistency. This is something we don't really care about though -- in fact, we don't care about the commit graph at all in this context but really only want to verify that no objects are missing.

Bisecting this failure points to upstream's f30e4d854b (fsck: verify commit graph when implicitly enabled, 2021-10-15). This commit has fixed a bug in git-fsck(1) where it only checked the commit-graph when the core.commitGraph config was explicitly enabled such that git-fsck(1) will now also do the check if the commit-graph is enabled via the default. So this explains why we have started to see the issue.

Fix the bug by explicitly disabling use of the commit graph in git-fsck(1). As explained above, we don't care about its consistency anyway and only want to verify that all required objects exist.

Changelog: fixed

closes: #3875 (closed)