Replace maintenance with 'git maintenance run'

[derrickstolee]

Scalar inherited its background maintenance model from VFS for Git, which does incremental maintenance by running some Git commands. Some of these steps have been implemented in Git proper, minus a few steps (such as verifying the file after writing it). We are working to move towards using the git maintenance builtin for all maintenance.

This PR is a step in that direction, but is in fact a half-measure.

1. Some steps, such as CommitGraphStep and PackfileMaintenanceStep still verify the written files in the C# layer since Git doesn't do that (yet).
2. Only Linux depends on git maintenance start to actually integrate with cron instead of using the Scalar.Service project.
3. The macOS platform could use git maintenance start instead of Scalar.Service (as in [WIP] [DO NOT MERGE] Drop Scalar.Service from macOS #416), but we keep it around to minimize the risk in this release.

There was a late change from earlier WIP versions: we need to support Git versions that are not the latest .vfs. release! This adds a GitFeatureFlags.MaintenanceBuiltin flag that is checked only if we are in version v2.28.0.vfs.1.0 or v2.29.0.vfs.0.0 or later. When this builtin is fully integrated into later versions of Git (v2.30.0 at minimum) then we can expand the feature flag. At that point, we will drop the parallel implementation in the C# layer that calls the commit-graph and multi-pack-index builtins directly.

This update to the Git version also takes a lot of dependencies in at once, but all that are available in v2.29.0. The most troublesome is git/git@1eb22c7 which changes the behavior of git multi-pack-index repack --batch-size=<size> to repack frequently. Combining this with the fact that we no longer specify a batch size through git maintenance run --task=incremental-repack, some functional tests needed to change to accommodate this.

Finally, we remove a lot of tests that check that the PackfileMaintenanceStep clears up bad prefetch pack data. This was necessary in VFS for Git to clean up bad data from a previous version, but is less necessary now. We will want to be aware of anyone accumulating too many temp files (from early-exiting Git processes) to see if git gvfs-helper needs to take some of these features.

The commits are laid out in this sequence.

Update the version of Git:

• Update Git to include maintenance builtin

Update some config schedules (only matters on Linux and future Scalar versions) and update GitFeatureFlags:

• ConfigStep: prepare maintenance config for background runs
• GitFeatureFlags: Maintenance builtin

Replace existing Git calls with git maintenance run --task=<task> when possible.

• GitProcess: enable 'git maintenance run --task={task}'
• CommitGraphStep: use the maintenance builtin, when available
• PackfileMaintenanceStep: use incremental-repack task
• LooseObjectsStep: use maintenance builtin
• FetchStep: always use Git to fetch data
• FetchStep: use maintenance builtin

On Linux, launch background maintenance with git maintenance start:

• ConfigStep: launch background maintenance through Git

Fix the functional tests as necessary, due to new behavior:

• FetchStep: remove tests that no longer apply
• FunctionalTests: adapt tests to new maintenance behavior

[derrickstolee]

/azp run microsoft.scalar

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[derrickstolee]

Note: this PR needs some decision points:

Do we only run maintenance if their Git version supports it? Or, do we keep the C# code around for a version? I think we should say "use our Git if you want maintenance."

[mjcheetham]

LGTM, just one question about git maintenance