Offline Mode: Fix background sync and media uploads integration

[kean]

It turned out to be not feasible to reliably implement the "Discard Changes" feature for draft posts. The team decided to remove this feature and save drafts automatically like on Android and Web. This change also better aligned with the "Preview" feature UI/UX (there was a separate discussion about it which I can't find now).

• Fix an issue where opening draft post for editing will terminate all media uploads for the post and hang the outstanding sync operations
• Fix an issue where closing and discarding a draft post will terminate all media uploads for the post and hang the outstanding sync operations
• Add an "Auto Save Draft" feature flag and the feature itself (autosave on "Back" taps and when the app is terminated)

Testing

Media Integration

Test 1.1

• Mocking: make sure all media uploads hang/fail
• Create and save a draft post
• Open the post and add an image
• Save draft (revision R1)
• Open the post again
• Wait until the image is uploaded
• Close the editor
• ✅ Verify that the draft eventually ends up in synced state (note: it does no work in trunk)

Auto Save

Test 2.1

• Create a new draft
• Tap "Back" (post has no changes)
• ✅ Verify that the post was deleted

Test 2.2

• Open a new draft
• Make some changes
• Tap "Back"
• ✅ Verify that the draft was saved automatically and uploaded to the server

Test 2.3

• Open an existing draft
• Make some changes
• Tap "Back"
• ✅ Verify that the draft was saved automatically and uploaded to the server

Test 2.4

• Open a new draft
• Make some changes
• Terminate the app (but NOT from Xcode debugger)
• Re-launch the app
• ✅ Verify that the draft was saved automatically and uploaded to the server

Regression Notes

1. Potential unintended areas of impact
2. What I did to test those areas of impact (or what existing automated tests I relied on)
3. What automated tests I added (or what prevented me from doing so): hard to count

PR submission checklist:

• [ ] I have completed the Regression Notes.
• [ ] I have considered adding unit tests for my changes.
• [ ] I have considered adding accessibility improvements for my changes.
• [ ] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Testing checklist:

• [ ] WordPress.com sites and self-hosted Jetpack sites.
• [ ] Portrait and landscape orientations.
• [ ] Light and dark modes.
• [ ] Fonts: Larger, smaller and bold text.
• [ ] High contrast.
• [ ] VoiceOver.
• [ ] Languages with large words or with letters/accents not frequently used in English.
• [ ] Right-to-left languages. (Even if translation isn’t complete, formatting should still respect the right-to-left layout)
• [ ] iPhone and iPad.
• [ ] Multi-tasking: Split view and Slide over. (iPad)

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Alpha
	Configuration	Release-Alpha
	Build Number	pr23091-a8d47dc
	Version	24.8
	Bundle ID	com.jetpack.alpha
	Commit	a8d47dce48b02c6689053d9e1422d4a278681ed0
	App Center Build	jetpack-installable-builds #8763

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.

	App Name	WordPress Alpha
	Configuration	Release-Alpha
	Build Number	pr23091-a8d47dc
	Version	24.8
	Bundle ID	org.wordpress.alpha
	Commit	a8d47dce48b02c6689053d9e1422d4a278681ed0
	App Center Build	WPiOS - One-Offs #9719

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[kean]

I found another fantastic media-related issue. Turns out, when the editor deletes an image block, you end up with an orphan media upload in post.media. It's problematic to say the least, especially if you end up with an orphan upload like this that has a file that can't be uploaded – e.g. too large or is not supported by the blog.

Steps (expected):

1. Mock a terminal failure (I prefer to override var maxUploadSize: NSNumber? to return a small nubmer of bytes)
2. Create a draft post
3. Add an image and verify that the upload fails
4. Remove the block (do NOT cancel the upload – this scenario works)
5. Tap "Publish"
6. ✅ Verify that the "Publish" button in the pre-publishing sheet is enabled

I don't think it's a show-stopper, but we need to find a solution during the beta period. I'm out of ideas. There are absolutely no unique identifiers that would allow me to check if the upload is still in post.content. I suggest fixing it separately.

[dvdchr]

Hi @kean 👋 , I'm bumping this PR's milestone to 24.9 since I'm starting code freeze. Feel free to re-target this to the release branch if this is a blocker or intended for 24.8.

[dangermattic]

	1 Warning
:warning:	This PR is assigned to the milestone 24.8 ❄️. The due date for this milestone has already passed. Please assign it to a milestone with a later deadline or check whether the release for this milestone has already been finished.

Generated by :no_entry_sign: Danger