Add basic implementation of YRoom

[dlqqq]

Description

Provides a basic implementation of YRoom, as described in #3. The YRoom:

• Initializes pycrdt.Doc() and pycrdt.Awareness() for a given file,
• Receives all new messages from connected clients for 1 YDoc,
• Uses a message queue to store messages while the file is being read from disk,
• Starts a background async task that continuously polls the message queue,
• Handles SyncStep1, SyncUpdate, and AwarenessUpdate messages using pycrdt, and
• Produces highly detailed warnings & errors to make debugging easier.

This YRoom does not do anything yet because it still requires:

• Some sort of file loader to read from & write to a file on disk using the Jupyter Server ContentsManager,
• A YRoomManager to initialize the file loader, and
• A YRoomWebsocket that calls methods on YRoomManager to start rooms when clients connect to one without other collaborators.

This PR also:

• Adds jupyter_server_fileid as a dependency,
• Adds empty interfaces for YjsClientGroup, YRoomManager, and YRoomLoader (name might change).
  • @jzhang20133 You can use the interface provided by this PR to implement YjsClientGroup.

Follow-up issues

• TODO: new issue for file loader
• TODO: new issue for YRoomManager
• TODO: new issue for YRoomWebsocket
• TODO: new issue for some kind of formatter like pre-commit. The code looks a bit ugly because of the long logging statements.

[jzhang20133]

broadcast messages to all clients could take a long time especially when there are many clients. It will make this call blocking and take a long time to finish and meanwhile, no other messages can be processed.

[jzhang20133]

In original implementation, there is a object stream buffer to hold those messages that need to be broadcasted and broadcasting in another task.

[dlqqq]

The issue is that tornado.websocket.WebSocketHandler.write_message() is synchronous. We could make this async by running this logic in a separate thread (e.g. via ThreadPoolExecutor), but I don't know if that will improve performance due to the Python GIL.

I think the best way to address this is to: 1) time this using logs for now, then 2) address this performance issue if it proves to be a concern. What do you think?

[jzhang20133]

The original implementation used a object stream buffer to break up the operations in half and achieve async broadcasting leveraging a object stream/queue. We could definitely come back to this in future PRs.

[jzhang20133]

Do we usually squash commits into one for each PR? Or we use that pattern. I am OK either way.

[jzhang20133]

Approve to unblock and we can address issues in future PRs

[dlqqq]

@jzhang20133 Yup, generally we squash all PRs before merging them to keep the commit history clean. Also makes backporting changes easier, which is important post-1.0.0.

[dlqqq]

More feedback from Jialin (that can be addressed in a future PR):

• Use a 2nd "update queue" that is added to whenever the ydoc observer fires. This allows us to guarantee that new updates are broadcast in order, and we don't have to rely on how the ydoc observer works in pycrdt.

• Consider bringing back the YjsClientGroup.get_others() method (N-1) instead of always broadcasting to all N clients.