Download all trees for non-prefetched commits when root tree is downloaded

[tyrielv]

This pull request will help mitigate the slower performance of prefetching the commit graph by improving the experience of common operations if run before the initial prefetch has completed - for example, git checkout or git log.

Changes:

1. TryGitIsBlob replaced with TryGetObjectType so that we can distinguish trees and commits separately with the same number of loads.
2. CommitAndTreeRootExists added an out parameter to make the tree root id available to caller so it doesn't have to be loaded again.
3. InProcessMount will track when a commit has been requested by the git read-object hook, and if the tree for the commit is also requested then it will use the batch API to download all the trees for the commit at once instead of waiting for individual tree requests to come from git.

[derrickstolee]

This is an interesting heuristic.

This will have a change not only for that one-time setup where the prefetch is happening in the background (via #1849) but also for any time that a user checks out a recently-updated remote branch but the cache server prefetch packfiles have not included them yet.

This will also affect any time that a user runs file history before a prefetch is complete, leading to many overlapping packfile downloads full of trees where most are shared.

I'm concerned enough about these long-term behavior changes that I don't want to sign off on this right away. The code does what is advertised, but I'm concerned about these longer-term issues.

[tyrielv]

This will have a change not only for that one-time setup where the prefetch is happening in the background (via #1849) but also for any time that a user checks out a recently-updated remote branch but the cache server prefetch packfiles have not included them yet.

Very good point - I didn't think about how it takes time for recent updates to make it to the prefetch packfiles.

This will also affect any time that a user runs file history before a prefetch is complete, leading to many overlapping packfile downloads full of trees where most are shared.

I intentional wanted to include history operations (I considered putting this in checkout hook instead of get-object hook), but that's a very good point about the level of duplication between them.

I'm going to do some more analysis of my problem scenarios and modify this proposal.

[dscho]

@tyrielv would you mind upgrading the GitHub workflows to use windows-2022 instead of windows-2019? (See actions/runner-images#12045 for details.)

[tyrielv]

@tyrielv would you mind upgrading the GitHub workflows to use windows-2022 instead of windows-2019? (See actions/runner-images#12045 for details.)

I've started taking a look (see #1851), but it seems neither windows-2022 nor windows-2025 include support by default for the .NET framework version that GVFS needs. I've tried a couple things but haven't had success so far.