[Yjs] Stateful file manager for yjs

[Wh1isper]

Problem

1. All file changes are stored in the same db file, This can lead to performance problems (Allow sqlite db to be saved in a different location jupyterlab/jupyter-collaboration#49)
2. Unedited files should be treated as static and previous collaboration records deleted (this means that the ydoc record for a file should be temporary), Otherwise, the user may rename the file and create a new one with the same name and then have problems

For example, if you create a new ipynb (Untitled.ipynb), write something and rename it, and then create another ipynb (Untitled.ipynb), the new Untitled.ipynb will not open on the front end...

Proposed Solution

A file open and close related management should be added, yjs websocket connection can be seen as a file open, the crdt algorithm to solve the conflict of multiple users editing at the same time, when no user open the file, the file should be returned to "non-collaborative state"

This means that the life cycle of the file editing db should be bound to the user's access.

Also, I haven't figured out how to handle it when the service restarts or crashes, so maybe it needs an elegant startup to go with...

Additional context

This problem may also be related to the horizontal scaling of the jupyverse

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[davidbrochart]

2. Otherwise, the user may rename the file and create a new one with the same name and then have problems

This issue should be mitigated with the file ID service. There is an open PR in jupyverse.

[Wh1isper]

This is a history management issue, and a single fileid manager may not be sufficient for all cases

It seems to me that single disks on Linux platforms can use ino for file uniqueness distinction(jupyter-server/jupyter_server_fileid#2 (comment)), as a way to link history files to real files, and remove history files when the link fails. But on other platforms, there doesn't seem to be a good means to do this without a service continuously monitoring the file system

I'm trying to implement a multi-user real-time collaborative data analysis service, but it may look similar to the problems Jupyter is currently facing but is different in nature