Avoid holding worktree lock for a long time while updating large repos' git status

[maxbrunsfeld]

Fixes #9575
Fixes #4294

Problem

When a large git repository's .git folder changes (due to a git commit, git reset etc), Zed needs to recompute the git status for every file in that git repository. Part of computing the git status is the unstaged part - the comparison between the content of the file and the version in the git index. In a large git repository like chromium or linux, this is inherently pretty slow.

Previously, we performed this git status all at once, and held a lock on our BackgroundScanner's state for the entire time. On my laptop, in the linux repo, this would often take around 13 seconds.

When opening a file, Zed always refreshes the metadata for that file in its in-memory snapshot of worktree. This is normally very fast, but if another task is holding a lock on the BackgroundScanner, it blocks.

Solution

I've restructured how Zed handles Git statuses, so that when a git repository is updated, we recompute files' git statuses in fixed-sized batches. In between these batches, the BackgroundScanner is free to perform other work, so that file operations coming from the main thread will still be responsive.

Release Notes:

• Fixed a bug that caused long delays in opening files right after performing a commit in very large git repositories.