fix(plugin-ext): skip plugin watches rooted at an ancestor of the workspace

[safisa]

What it does

Fixes #17632

The backend ignores the recursive flag and always watches recursively, so a non-recursive watch rooted outside the workspace becomes a full recursive crawl. JDT-LS (redhat.java) watches the parent of the workspace folder (sent as recursive: false) only to detect its deletion — Theia then crawls every sibling of the workspace folder and can exhaust fs.inotify.max_user_watches; files.watcherExclude can't help since the root is outside the workspace.

MainFileSystemEventService.$watch now skips a non-recursive watch rooted at a strict ancestor of a workspace root; recursive requests and on/inside-workspace watches are unchanged. The root-cause alternative (a real non-recursive watcher, à la VS Code) is larger — both options are in #17632.

How to test

Linux, workspace alongside large siblings under a shared parent, with Red Hat Java (JDT-LS, non-LightWeight): via the diagnostic on #17630 or inotify-consumers, the parent's sibling trees are no longer watched. Covered by unit tests in main-file-system-event-service.spec.ts.

Follow-ups

Root-cause non-recursive watcher tracked in #17632; trade-off: loses workspace-folder-self-deletion detection for the skipped watchers.

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines
• User-facing text is internationalized using the nls service (for details, please see the Internationalization/Localization section in the Coding Guidelines)

[colin-grant-work]

This is an expedient fix, but I wonder whether we could, without too much difficulty, follow VSCode's example and add non-recursive watching as a feature, rather than dropping these watches?

[colin-grant-work]

In a multi-root workspace where one root is a parent of another, a watch of the outer folder would fail here.

[safisa]

Good catch — fixed in 3cfc636. A folder that is itself a workspace root is now never skipped; the check only drops watches rooted strictly above every root. So in your nested multi-root example (/projects and /projects/my-app), a non-recursive watch on /projects is still registered. Added a regression test (still registers a non-recursive watch on an outer root that is itself the parent of another root).

[safisa]

Re: adding non-recursive watching as a first-class feature instead of dropping these watches — I looked into the feasibility.

The obstacle is the backend watcher: Theia's recursive watcher is @parcel/watcher, whose subscribe() only accepts { ignore, backend } and is always recursive — it has no non-recursive mode. The recursive flag is already carried from the frontend through the RPC layer, but it's dropped in DiskFileSystemProvider.watch (the backend filesystem-watcher-protocol WatchOptions only has ignored, no recursive).

So matching VSCode's approach would mean adding a separate fs.watch-based non-recursive watcher (VSCode routes non-recursive requests to its own NodeJSWatcher precisely because parcel can't do it), plus request routing and plumbing the flag end-to-end through the protocol — a sizable, separable change rather than a small tweak. My preference is to land this bounded mitigation now; first-class non-recursive watching could be pursued as a separate enhancement.