♻️ Use LSP based file watcher

[SPGoding]

Resolves #1414.

For testing purposes, the Output tab includes outputs prefixed with [FsWatcher] with the raw LSP changes, added files, changed files, and unlinked files, whenever file system changes are detected.

[SPGoding]

During testing I noticed there was a bug with VS Code's built-in file watcher:

0. Create a file at a/b/c/file.txt
1. Rename a to a2
2. Rename c to c2

Expected Results:

Raw LSP changes should include

{
  changes: [
    {
      uri: 'file:///a2/b/c2',
      type: 1
    },
    {
      uri: 'file:///a2/b/c',
      type: 3
    }
  ]
}

Actual Results:

Raw LSP changes instead include

{
  changes: [
    {
      uri: 'file:///a/b/c2',
      type: 1
    },
    {
      uri: 'file:///a/b/c',
      type: 3
    }
  ]
}

Notice that folder a2's old name a is shown in the output. The new LspFsWatcher will be unable to send correct events as the path included in LSP raw changes does not actually exist.

[misode]

During testing I noticed there was a bug with VS Code's built-in file watcher: [...]

@SPGoding During testing I could not reproduce this issue. I correctly get the addition of 'file:///a2/b/c2', and removal of 'file:///a2/b/c'. Either this is OS-dependant or I am following the steps incorrectly.

Regardless of me being able to reproduce, is this a blocking issue meaning we can't go forward with this LSP based watcher approach? Or are there workarounds to resolve this?

[misode]

In addition to solving the renaming bug on Windows, this also seems to greatly improve performance! While before it would take upwards of 60 seconds to load the Gamemode 4 repo (cached), it now only takes 16 seconds!

I experienced one issue when deleting a very large folder, with a OOM crash.

[misode]

In #1607 Afro started working on being able to exclude certain patterns from the watcher. From testing, the watcher seems to be very performant so this may not be necessary, but I did see raw LSP changes in .git/FETCH_HEAD for example. Do these have potential to break anything? If we want to do any filtering, should we do it here or later in LspFsWatcher.onLspDidChangeWatchedFiles?

[misode]

This seems like the biggest performance concern. I tried deleting a huge nested folder (2k+ files) in an already huge project (Gamemode 4, 45k+ files). Instead of sending a single Deleted change object, the vscode LSP watcher decided to send a changes list containing 2k+ elements. This doesn't happen when deleting normal sized folders. In the output log, I saw that it was logging a single unlink event roughly every 6 seconds, and it crashed with out of memory about a minute in.

Would it make sense to skip looping over all watched files to find nested files if the first condition (this.#watchedFiles.has(uri)) matches? If that's the case a file was deleted and no nested files should exist.

[SPGoding]

Would it make sense to skip looping over all watched files to find nested files if the first condition (this.#watchedFiles.has(uri)) matches?

That would be a nice change

I also think this could be potentially optimized further by using a tree structure to keep the #watchedFiles instead of using a flat string set, but that might involve some changes to Project as well.