Dispose ydocs provider when closing app

[farmaazon]

Pull Request Description

This fixes an effect of an old project's node being displayed when opening another one. I discovered those old nodes were read from YDocs server. I suppose this is some process from old project still interfering with ydocs (but I don't know how exactly - we're supposed to have different docs for each language server, aren't we?). Anyway, disposing ydocs provider on app unmount looks like good idea, and it fixed the issue.

It does not resolve problem with connection retries after closing project (#8964)

Screencast.from.2024-02-07.14-53-00.webm

Important Notes

Perhaps the better way would be to assume the pinia (or maybe entire gui2's App) persists between projects and just have configuration updated (and on update reconnect with different LS + change used ydocs server endpoint). But this is a harder task. Any discussions here are welcome.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• [ ] The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• All code has been tested:
  • [ ] Unit tests have been written where possible.
  • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

[kazcw]

This is definitely an improvement.

I'm concerned we might have other issues, currently or in the future, when changing projects. We mainly test the GUI by opening a project starting from a clean state. When we switch projects and all the Pinia stores have to be transition from one initialized state to another, we could easily have other problems. If we were to reset our Pinia stores (some approaches here: vuejs/pinia#911) when closing a project, store setup would only need to correctly handle starting from an uninitialized state, and we would not have any risk of observing data from a previously-opened project.

[vitvakatu]

Let’s merge this one.