Incredible slow sync due to interrupted storing

[giomfo]

Matthew complains on incredible slow sync, this appends when the previous saving was interrupted.

Notify the user should be useful here

[giomfo]

We suggest keeping the existing storage until the end of the saving process.
The application should write the new data by creating new files, the existing storage will be replaced at the end of the saving.
If the saving is interrupted, the existing storage will be used to restore the local storage.

The saving process may still be interrupted when the existing storage is replaced, but this operation is faster. The probability to detect a corrupted storage should be reduced.

We still need to notify the user when the local storage is reset to fix file corruption.

[ara4n]

Brief notes from talking to @manuroe about this on Monday:

I think we can fake atomic saves with rollback without having to resync the world, and without switching to using realm.io or similar:

• persist per-room events/state to: ./messages/!curbaf:matrix.org-${previous_sync_token}.
• rename the file for the room after persisting them to replace the original
• if things crash during peristence, then on launch:
  • look for partially any persisted files with the -${previous_sync_token} suffix
  • load up all the existing non-partial files
  • start /sync-ing again from the $previous_sync_token in the partial filename.

If there were local echos being persisted in the partial file, then they will obviously get lost when resyncing from /sync results, but c'est la vie.

[manuroe]

FTR, MXFileStore files has been reorganised like this: https://github.com/matrix-org/matrix-ios-sdk/blob/13cd0c3f6f16cfe6dc8c87055de98ed74d7d0616/MatrixSDK/Data/Store/MXFileStore/MXFileStore.h#L27