Dispose of watchers in serverless function code

[datho7561]

One part of #3120

Signed-off-by: David Thompson davthomp@redhat.com

[codecov]

Codecov Report

Patch coverage: 37.93% and no project coverage change.

Comparison is base (843dca5) 32.97% compared to head (8a49a36) 32.97%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3139   +/-   ##
=======================================
  Coverage   32.97%   32.97%           
=======================================
  Files          75       75           
  Lines        5244     5265   +21     
  Branches      996     1000    +4     
=======================================
+ Hits         1729     1736    +7     
- Misses       3515     3529   +14     

Files Changed	Coverage Δ
src/serverlessFunction/functionImpl.ts	26.59% <31.37%> (+1.26%)	⬆️
src/serverlessFunction/view.ts	33.33% <80.00%> (-0.24%)	⬇️
src/extension.ts	66.66% <100.00%> (+0.35%)	⬆️
src/util/workspace.ts	37.50% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[datho7561]

Test failures seem legitimate and indicate that a modal has popped up, preventing interaction with VS Code. This usually means that VS Code is alerting the user that an extension has failed badly. I'll have to investigate. resolved

[vrubezhny]

This change looks good to me... but it's not enough...

When I have running the development vscode instance, plus started debugging the extension (with this PR included), then started Dev for a component in OS View and then...
... in Systen Terminal (outside of any vscode nstance) command line I run npm test, I heve the following test failed:

  File Watch Utility
      ✔ watchFileForContextChange ensures the location exists: 0ms
      ✔ watchFileForContextChange creates a file watcher for the given path: 1ms
      ✔ watchFileForContextChange returns a content change notifier: 0ms
      1) emits change message when context changes
  Suite duration: 0.014 s, Tests: 4
...
  1 failing
  1) File Watch Utility
       emits change message when context changes:
     Error: EMFILE: too many open files, watch '/tmp'
      at FSWatcher.<computed> (node:internal/fs/watchers:244:19)
      at Object.watch (node:fs:2322:34)
      at Function.watchFileForContextChange (src/util/watch.ts:18:46)
      at /home/jeremy/projects/vscode-openshift-tools/source/vscode-openshift-tools/test/unit/util/watch.test.ts:57:36
      at Generator.next (<anonymous>)
      at /home/jeremy/projects/vscode-openshift-tools/source/vscode-openshift-tools/out/test/unit/util/watch.test.js:12:71
      at new Promise (<anonymous>)
      at __awaiter (out/test/unit/util/watch.test.js:8:12)
      at Context.<anonymous> (test/unit/util/watch.test.ts:52:66)
      at processImmediate (node:internal/timers:466:21)

Test failures: 1
Exit code:   1
Failed to run tests

Which brings me to WatchUtil.watchFileForContextChange(...) creating a File Watcher and at least two client views which invoke this method (and close the File Watchers) plus the test itself which never close the produced File Watchers.
I don't believe that two File Watchers opened by the utility method client views can male the file watcher counter to overload, but the test cases for sure should also close the created File Watchers as this can force the subsequent tests or some functions of the running extension to fail.

UPD: Tests do not invoke the real fs.watch(...) because it's "sandboxed" and as such it doesn't create any FSWatcher objects.
UPD 2: There is still one test case that really invokes fs.watch - see: #3148.

[vrubezhny]

Looks good to me

[datho7561]

I'll address the comment about the test in this PR as well; might as well.

Didn't realize you already had a PR open to do this.