Desktop: Prevent the remote version of a note being overwritten if typing while the sync changes the open note

[mrjo118]

This PR fixes equivalent issues to PR #16193 which are present in the desktop app.

Changing the note contents within about 0.5 seconds before the note is reloaded via an update by the sync, can cause the remote version to be overwritten with the local contents in the current editor. This can be a serious data integrity issue, particularly with the upcoming introduction of automatically resolved conflicts, where the resolved version could also get lost as a result of multiple possible race conditions.

This PR addresses the issue by implementing the following for the mobile note editor:

1. Block saves scheduled before reload: Scheduled saves will now set the value of the editorNoteReloadTimeRequest prop at the point of enqueuing, and when the save is executed, it will be rejected if the editorNoteReloadTimeRequest value has since been moved on. This value is incremented by the reducer handling of the EDITOR_NOTE_NEEDS_RELOAD event, which is triggered immediately when the sync or a conflict updates a note. The EDITOR_NOTE_NEEDS_RELOAD handling in the reducer has been amended to support holding a separate editorNoteReloadTimeRequest state per window, while remaining compatible with mobile
2. Block scheduling new changes during reload: This is implemented by populating a reloadInProgress prop when a reload is triggered, and marking it as completed only once the editor has completed the reload. With this state established, the NoteEditor.onFieldChange function is blocked while true. Various places are also rejected when the editorNoteReloadTimeRequest value has changed since an action was triggered (including the execOnChangeEvent() function of the TinyMCE editor, which triggers after a 1 second debounce). Additionally a race was addressed in useFormNote where the existing change handler races with the EDITOR_NOTE_NEEDS_RELOAD handling. This covers changes to the title, MDE, RTE and plain text editor. Additionally, the editor and title components are marked as disabled during this transition in all cases
3. Blur the editor and title field while a reload is in progress: This is done to immediately reject user input and dismiss the on screen keyboard, as continuous typing can prevent the editor from being able to refresh. This applies to any note window which is currently in focus

Note that when typing really fast, it is possible to lose some of the text typed in the last second or so, but this is much better than losing the entire changes from remote versions or auto merged conflicts.

Testing

Manual testing covered the following scenarios:

• Verified very fast typing while sync updates the current note is halted when the refresh occurs, and nothing is overwritten
• Verified for the MDE / RTE / plain text editor and title field, that the refresh while typing causes a blur, which breaks the flow of the constant typing
• Verified when exiting switching note after the above scenarios, that the new state shown is what was saved, where nothing else was changed post reload
• Verified normal note changes are saved and persisted
• Verified external editing behaviour is unaffected
• Verified the fix works with and without E2EE enabled

Original behaviour:

Ojd2LZCHZj.single.change.mp4

New behaviour, demonstrating no content overwritten for the title, MDE, RTE and plain text editor without encryption enabled (note I accidentally used the legacy markdown editor for most of the MDE tests, but I did a thorough test with CM6 too):

5fsWmgfdWt.fix.all.no.e2e.mp4

New behaviour showing a few tests with E2EE enabled:

xLaqbzP8UN.new.md.e2ee.mp4

[coderabbitai]

.