re: New higher-performance rnote file format, and atomic file saving

[anesthetice]

The overall goal of this PR is to improve the handling of .rnote save files.

tl;dr

• Shorter loading times (~10x improvement*)
• Shorter saving times (~6x improvement*)
• Smaller file sizes (~12% reduction)
• Safer saving mechanism

* improvement factor measured only with respect to EngineSnapshot <-> bytes

Main changes:

• parallelized serialization and compression
• direct loading pathway when compatible
• for compression, using zstd instead of gzip
• atomic file saving (also applied for autosaves)

Here's a diagram of the simplified process to get from EngineSnapshot to a .rnote save file and vice-versa.

fixes #1128

Note that this PR is a re-write of #1177, some of the important changes being:

• (+) parallelism for serialization and compression
• (+) the introduction of a file version separate from the version of Rnote
• (-) scrapped save preferences (not worth complexity cost)
• (-) scrapped alternative serialization methods (for compatibility reasons)

[anesthetice]

@flxzt, @Doublonmousse, I'd say this PR is ready for review. Take all the time you need of course, and feel free to ask me for information, changes, etc. 🫡

[Doublonmousse]

Another thought on the atomic saving denomination.
I'm not sure we can really call the new version atomic saving per say.

That would be the case for a file format where any change we do inside the file is mapped back to the file through an efficient diff (and not a full write of the new engine state). For sqlite (#1173 (comment)), that would be the case because modifications to the file can be mapped back to the file through a push/commit

[anesthetice]

Another thought on the atomic saving denomination. I'm not sure we can really call the new version atomic saving per say.

That would be the case for a file format where any change we do inside the file is mapped back to the file through an efficient diff (and not a full write of the new engine state). For sqlite (#1173 (comment)), that would be the case because modifications to the file can be mapped back to the file through a push/commit

I have seen "atomic saving" be used to mean somewhat different things, but for the most part it seems to mean what we are doing here (Geany wiki, 15 year old stackoverflow thread, etc...). A more efficient saving mechanism using diffs might be interesting, but would probably be very complex to implement and then have to deal with forward- and backward-compatibility...

That being said, we should maybe tinker a bit more with the implementation as for instance metadata, permissions, and symlinks are not handled...

[anesthetice]

@Doublonmousse Apologies for the delay, let me know what you think