fix(setInitialYjsState): do not push or save the initial state on open

[silverkszlo]

📝 Summary

Opening a document without a stored yjs state applied the generated initial state as a local update. It was then pushed to the server like a user edit, which marked the document dirty and triggered an autosave, even for a freshly created and untouched document.

Apply the initial state with the sync provider as origin so it counts as received from the server. The provider sends diffs against the known server state, so the first real user edit still carries the initial state along with it.

🏁 Checklist

• Code is properly formatted (npm run lint / npm run stylelint / composer run cs:check)
• Sign-off message is added to all commits
• Tests (unit, integration and/or end-to-end) passing and the changes are covered with tests
• Documentation (README or documentation) has been updated or is not required

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI tools
• The AI-generated content was reviewed, comprehended and tested by a human

[max-nextcloud]

Background / history of the code

There's a bit of history to the code in question. We used to have an issue where opening a .md file would also write it back to the storage with the syntax adjusted by text. This used to happen when the document contained headings because the table of content used to change the content of the prosemirror document creating an update which would trigger the autosave.
I believe the headings issue has since been fixed - but altering the document can still happen for various reasons. So we used to check if the editor had changes tracked in it's history - i.e. if the undo or redo actions were possible. Only then we would autosave the changes.
I remove this check here when adjusting the autosave things:

Instead we now autosave on changes pushed:

[max-nextcloud]

This change

This change avoids pushing the initial step - that is the step that loading the initial document creates - to the server. In theory every client will create that step on its own based on the file content. We made the step deterministic on purpose so it could be generated based on the file content and then still be applied when received from the server.

I'm not sure if we are currently generating the step when already receiving steps from the server. But that could be adjusted. In my mind the full set of steps thus far always was enough to sync the y doc to the latest. This would not be the case anymore if we merge this PR. In addition to the steps we'd always rely on the initial markdown content.

The initial markdown content will be overwritten with the first autosave. At the same time this autosave also pushes the document state which includes the initial step - so the content is not needed anymore. So far the document state is a compressed form of all the steps leading up to it. So in a way it is redundant. This change would make it so it's not redundant anymore as the initial content would be overwritten and only stored in the document state.

I can't think of any breakages as consequences of this change but I'd argue that this makes the overall system less robust against race conditions.

[max-nextcloud]

Alternatives

I'd prefer a change that does not change the data flow between the server and client but only the initial autosave behavior. Two possibilities come to my mind:

• Do not emit the changesPushed event on the initial push.
• Bring back the test to not autosave unless the editor has undo or redo history.

I don't like either of the two as they both involve coupling the SyncService or the SaveService closer to the editor.

One variant that would decouple the save from the sync would be to trigger the autosave from within the editor based on changes to the editor independently of the sync requests. Thus far the logic has been:

• We pushed steps to the server... therefore we need to autosave.
  Then the logic would be:
• The user edited the document... therefore we need to autosave.