Fix indefinite line tracker suspension after closing large dirty editor

[gluxon]

Description

Fixes #3066. See issue link for an in-depth explanation of the bug, steps to reproduce, and a video.

Checklist

• I have followed the guidelines in the Contributing document
• My changes follow the coding style of this project
• My changes build without any errors or warnings
• My changes have been formatted and linted
• My changes include any required corresponding changes to the documentation (including CHANGELOG.md and README.md)
• My changes have been rebased and squashed to the minimal number (typically 1) of relevant commits
• My changes have a descriptive commit message with a short title, including a Fixes $XXX - or Closes #XXX - prefix to auto-close the issue that your PR addresses

[gluxon]

I was brainstorming a few alternatives to this approach.

1. Instead of the indirection through GitLineTracker, we could also call this.resume() right here. That felt strange since nothing else in lineTracker.ts suspends or resumes the tracker. This feels like a gitLineTracker.ts responsibility based on what's written today.
2. We could call this.fireDocumentDirtyStateChanged in the window.onDidChangeActiveTextEditor handler. This feels like a reasonable alternative approach to me. The main downside is that it's a bit of a slippery slope with regard to what document-specific change events are re-fired when the active editor changes. Ex: Would we also want to call onBlameStateChanged when the active editor changes?

I settled on the current approach, but happy to consider others in more depth if others have thoughts.

[gluxon]

Testing

Here's a test double checking that the original issue is fixed. A video of the original bug is present in #3066.

Fixed.mov

[gluxon]

I found it surprising that the GitLineTracker disappears completely while a file is dirty for 5 seconds and completely disappears for large dirty files. It makes sense that GitLens shouldn't compute diff frequently while editing, but I wonder if we should show its status in the user interface?

One idea would be to show an hourglass similar to what GitLens currently does as you move between lines. On hover, the indicator would show why it's delaying blame computation with a suggestion to tweak advanced.blame.sizeThresholdAfterEdit or advanced.blame.delayAfterEdit.

[eamodio]

Thank you so much for your contribution here! Great investigation work and resolution! I've merged this directly, but I will be making some further changes to unify the LineTracker and GitLineTracker (no real need for the separation at this point), and will look into some kind of "notification" statusbar or something to let the user know why things are suspended and be able to point them to changing values to tweak it if you want more responsiveness and can spare the extra compute overhead

[gluxon]

Thanks so much for reviewing this! Further changes post-merge are all welcome. I appreciate you taking the time to consider my thoughts.

[eamodio]

Refactored things a bit here:
e522866

And added the following when the delay is active -- clicking on the link will jump to the setting in the settings UI

And this when the file is over the threshold -- clicking on the link will jump to the setting in the settings UI

FYI, the default delay is 5000 ms and the default line threshold is 5000, the numbers above in the screenshots was just me testing

[gluxon]

That looks fantastic! Love it.