Store: Reset change detection on post update

[aduth]

Fixes #6112

This pull request seeks to resolve an issue where changes made while a post is saving are not accurately reflected in change detection, resulting in the potential for data loss if the user attempts to navigate away after a save completes.

In doing so, it also introduces...

• E2E tests for various "dirty post" prompt conditions.
• A fix for the withChangeDetection higher-order reducer where ignored action types may have resulted in the isDirty value being lost.

Testing instructions:

Verify that end-to-end tests pass:

npm run test-e2e

Repeat steps to reproduce from #6112, verifying that the editor prompts about unsaved changes if they were introduced in the time between save start and save success.

[aduth]

Failing tests have been resolved in 23889c8 to use platform-dependent modifier key, which makes sense since our use of mod+s in EditorGlobalKeyboardShortcuts would be interpreted by Mousetrap as control.

But then it makes me wonder how meta+a works in multi-selection end-to-end tests (cc @youknowriad).

We have another instance of this in meta box tests. What I think is happening here (and also susceptible in this pull request) is that the Ctrl+S save isn't occurring, but the autosave kicks in 10 seconds later automatically, satisfying the previous waitForSelector. We might want to think of a way to account for this in tests (either disable autosave, check for it explicitly, shorten timeouts, etc).

[youknowriad]

Can you clarify why it should return true on mid-save?

[aduth]

Can you clarify why it should return true on mid-save?

The fix here is moving the change detection reset from RESET_POST to UPDATE_POST, so immediately upon hitting save, before the request has finished. This means that we can track changes that occur while the save is in-flight. Conversely, we need to make sure that if the user attempts to navigate away while the save is still pending, they're notified.

Another (better?) way to express this might be to consider whether there are any transactions in redux-optimist where isDirty: true; i.e. is there a possibility that if the transaction (save attempt) was to be reverted (save fail), would the user be put back into a state of dirtiness?

I'd also considered if we could track changes more like what we had, with it being a condition of the current state: This is simple enough to check if there are any entries in state.editor.entries, but state.editor.blocksByUid and state.editor.blockOrder is harder to track for changes (without comparing to an initial value).

[aduth]

I thought meta would trigger "Ctrl" on windows?

Meta exists and has its own meaning in Windows (Windows key), though not always consistently applied by browsers apparently in treating event.metaKey.

https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/metaKey

[aduth]

Rebased.

e7f6b1c adds a new utility for end-to-end tests, pressWithModifier, which accepts "Mod" as an argument to translate to the platform-specific key. Existing usage has been updated, along with that in the newly-introduced tests.

978f8d5 avoids isSavingPost in the isEditedPostDirty selector, instead deferring to a new inSomeHistory selector which accepts state and a predicate function. Essentially this is the alternative behavior described in #6209 (comment), where dirtiness is a condition of whether the editor is currently dirty, or a pending-but-not-committed transaction could put the editor back into a dirty state.

[youknowriad]

This is causing a regression for the post publish panel, it's getting closed right after publish