Cannot switch file ID managers with same database

[davidbrochart]

Description

Switching file ID managers from e.g. LocalFileIdManager to ArbitraryFileIdManager doesn't play well with the database:

    HTTPServerRequest(protocol='http', host='127.0.0.1:8888', method='GET', uri='/api/yjs/roomid/Untitled.ipynb?1666790876574', version='HTTP/1.1', remote_ip='127.0.0.1')
    Traceback (most recent call last):
      File "/home/david/mambaforge/envs/jupyterlab/lib/python3.10/site-packages/tornado/web.py", line 1713, in _execute
        result = await result
      File "/home/david/github/davidbrochart/jupyter_server_ydoc/jupyter_server_ydoc/ydoc.py", line 310, in get
        idx = file_id_manager.index(path)
      File "/home/david/github/davidbrochart/jupyter_server_fileid/jupyter_server_fileid/manager.py", line 138, in index
        cursor = self.con.execute("INSERT INTO Files (path) VALUES (?)", (path,))
    sqlite3.IntegrityError: NOT NULL constraint failed: Files.ino

Reproduce

1. Run JupyterLab in collaborative mode and LocalFileIdManager installed, and open a file.
2. Run again JupyterLab with an ArbitraryFileIdManager, and open the file.
3. See the error above.

Expected behavior

Should we use a different database when switching file ID managers? If yes, this issue can be closed.
Otherwise, I'm not sure we should have filesystem-specific attributes in the database. I understand it is needed for local filesystems, but maybe we should give it a more abstract name? In the end, it is some kind of identifier. And other file ID managers might not have this notion, so maybe we should allow it to be NULL?

[kevin-bates]

I think the notion is that each implementation brings its own database schema. I imagine that ArbitraryFileIdManager could become the base class for most implementations (including those based on filesystems that don't want to get down into filesystem details and idiosyncrasies) since it will likely be predicated purely on the event system.