Fix the case where lazygit struggles with index.lock in very large repos

[edhgoose]

I've been repeatedly hitting index.lock issues as per #5906.

It's happening in a large repo (the one I hit this in has ~397k tracked files across ~62k directories).

I've found the issue stems from the use of --untracked-files=all as the default for running foreground git refreshes. In this case it can take 2-4seconds to track all the untracked files. This is because --untracked-files=all runs over every single file in the repo, and it doesn't use the core.untrackedCache from git.

You can see some example runs of git status (outside of lazygit) in the details below:

Example git status commands

$ time git status --untracked-files=all
On branch master
Your branch is up to date with 'origin/master'.

It took 2.56 seconds to enumerate untracked files,
but the results were cached, and subsequent runs may be faster.
See 'git help status' for information on how to improve this.

nothing to commit, working tree clean
git status --untracked-files=all 0.37s user 1.98s system 89% cpu 2.626 total

$ time git status --untracked-files=all
On branch master
Your branch is up to date with 'origin/master'.

It took 2.11 seconds to enumerate untracked files,
but the results were cached, and subsequent runs may be faster.
See 'git help status' for information on how to improve this.

nothing to commit, working tree clean
git status --untracked-files=all 0.38s user 1.92s system 106% cpu 2.165 total

$ time git status --untracked-files=normal
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
git status --untracked-files=normal 0.14s user 0.14s system 106% cpu 0.263 total

$ time git status --untracked-files=normal
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
git status --untracked-files=normal 0.12s user 0.12s system 106% cpu 0.231 total

There's a mitigation for this case in lazygit added via a lock retry mechanism in #5788, but because it only tries 7 times, the maximum length of the retry is ~1.26 seconds, which is below the 2-4 seconds I've been seeing it takes to run the command.

I've found the right answer is to set the status.showUntrackedFiles value to normal (git config --global status.showUntrackedFiles normal or git config status.showUntrackedFiles normal for this specific repo) as lazygit obeys that, but I thought lazygit could be more intelligent for this edge case.

This PR adds a change to automatically skip to "normal" mode (instead of "all") when the volume of files exceeds a threshold.

It'll always obey a users setting if one is set too.

There is one clear downside to this, which is that when a user adds a directory, they will see this experience:

But I think this is better than the locking experience I've had.

Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc