Better terminology for database tables from NC 30 on

Is your feature request related to a problem? Please describe.
The current terminology, database structure and flow for sync have been inherited from the tiptap 1 sync mechanism. This is confusing.

Describe the solution you'd like

• session -> connection: These are actually connections from one client to the server. They are temporary and when the client reconnects it gets a new connection.
• document -> ydoc: This is actually the metadata for one ydoc evolving over time.
• steps -> sync_messages: yjs messages to keep the ydoc in sync.

Using the same data formats for messages

• Send one update message per request. (Generate it when sending the request).
• Store one update message per database entry.
• Send full document history as an update message including bits indicating its a sync update.
• Store the full doc history in the messages table along other messages with a flag indicating its a full sync

Open questions

What do we do with awareness messages?

Describe alternatives you've considered

• Keeping the names as they are - confusing
• Creating new table and structure from scratch - I'd rather go incrementally - but might be worth a second thought.

No files, tests, or entry points are named. Start by locating the existing sync database tables and message flow, then compare the proposed connection, ydoc, and sync_messages terminology and data-format changes; resolve the awareness-message question before defining completion.