Fix regression from batch object downloads

[derrickstolee]

This is a fix for a performance regression introduced by #822. That change updated the packfile installation process to call a different packfile installation method after some upstream changes to the packfile data structures.

However, while I thought I read the new packfile methods as including a modification of the MRU cache, it apparently does not fully install the packfile in the list.

This manifests in something like git checkout where the missing blobs are queued for download, downloaded in blob packfiles, and then the checkout process continues. During the process of writing the data to the worktree, the "updating files" progress indicator slows to a crawl because it was "missing" the blobs and then downloaded them on-demand.

This fixes the issue by being less fancy about packfiles and using packfile_store_reprepare() to just reset the full packfile list. This is more future-proof and isn't very expensive compared to the packfile download.

I augmented a test to include tracing that shows a necessary blob is queued for packfile download and is not later downloaded via an immediate request. Without the code change, that test would fail.

• This change only applies to interactions with Azure DevOps and the GVFS Protocol.

[dscho]

Thank you so much!