Use Automerge doc for user state

[kasbah]

This is ready for review but I suggest we wait for "Performance regression on main" (automerge/automerge#1159) to be resolved before deploying to production. As it stands it takes 100ms to create a new user state when the user first visits the site which manifest in a delay of seeing any documents if cold visiting /documents.

Closes the "server side state" part of #881 by implementing Automerge docs, derived from the db data, for every user state. Mutations are still handled through regular RPC calls. The UserState mainly holds the document lists and some user information and is put into a Context on the frontend.

I couldn't resist slightly improving the UI of "My documents" and "Trash" since I had to replace them anyway. The overall feeling of reactivity of the document titles and the user names is very nice.

---

I am not sure how useful it is, but inspired by Benjamin Pierce's Colloquium talk, I made a commutative diagram of the paths I used property based testing on.

$$t_1$$	write_user_state_to_db	Writes a UserState to the database (testing only).
$$f_1$$	read_user_state_from_db	Reads a UserState from the database.
$$f_2$$	run_user_state_subscription	Listens for Postgres notifications related to user state changes.
$$g$$	user_state_to_automerge	Converts a UserState into an Automerge document.
$$t_2$$	automerge_to_user_state	Converts an Automerge document to a UserState (testing only).

Note that run_user_state_subscription will be fine in normal usage but if you e.g. use ALTER TABLE by loading a dump or something the automerge doc will be inconsistent with the DB. read_user_state_from_db is run on request at the start so re-starting the server will fix the inconsistencies.

Here is a very imperfect schema for the UserState. (Imperfect since we can't really represent Vec<T> or Option<T> where T is an entity in the schema on CatColab -- also papering over how things are referred to, directly or via ID.)

https://catcolab.org/model/019cae54-2940-7971-9060-dcd2b8657ff5/analysis/019cae83-2b0a-7062-85a8-ceb4d1665c46

[kasbah]

In happy news Automerge, Autosurgeon and Samod have all gotten a release with the performance improvements. 🚀 🎉 I've upgraded them here.

[epatters]

Thanks Kaspar. There's a lot to process here. I've left some questions/comments focusing on the backend piece. I'll try to make another pass soon.

My overall impression is that I'm glad the complexity has shifted from Postgres queries/notification log to Rust code, because I think the Rust code will be easier to maintain and involves less magic. That said, the code footprint on the backend is quite large and going forward the complexity of adding new features to the backend will increase. So I'm really hoping that this is worth it on the frontend side, both in terms of dev experience and user experience.

[jmoggr]

Are the performance concerns mentioned here:

Since we are not using the public docs at the moment I have removed them for now and will leave performance optimization for another PR.

Addressed by this?:

In happy news Automerge, Autosurgeon and Samod have all gotten a release with the performance improvements. 🚀 🎉 I've upgraded them here.

I think benefits of the user-state-doc decrease if we need a parallel system for public docs. I'd be happy to help out with that or explore feasibility.

[kasbah]

@jmoggr

Are the performance concerns mentioned here:

Since we are not using the public docs at the moment I have removed them for now and will leave performance optimization for another PR.

Addressed by this?:

No, they are not.

I think benefits of the user-state-doc decrease if we need a parallel system for public docs. I'd be happy to help out with that or explore feasibility.

It's not really public vs private it's just the number of docs I believe. We might need different ways of determining "these are the docs the user cares about right now", though with that we are sort of back to something akin to paginating I guess.