Describe the bug

If an autosave revision exists for a published post (or draft authored by another user), and non-content field edits exist, isEditedPostAutosaveable wrongly returns true, resulting in a 400 bad request response from the autosaves endpoint.

To Reproduce

Steps to reproduce the behavior:

1. Navigate to Posts > Add New
2. Enter a title
3. Publish the post
4. Change the title
5. Press Preview
6. Close Preview tab
   • (Ignore fact it may or may not redirect to the preview)
7. Reload the page, dismissing the prompt about unsaved changes
8. Note there is an "Autosave exists" notice
9. Toggle the post as "Stick to the Front Page" in Document settings
10. Press preview

Expected behavior

There are no changes to the saved copy of the post to be previewed (title, content, excerpt), so the preview window should direct to the saved post link and not initiate a request to the autosaves endpoint.

Actual behavior

The "Preview Loading" interstitial is wrongly displayed. A request is sent to the autosaves endpoint and responds with a 400 Bad Request code.

Possible solution

The isEditedPostAutosaveable selector returns early with true if there is no known autosave:

In the above flow, an autosave exists but it is not known to state. A solution may be to simply ensure that the autosave is populated at the start of the editor session, so it can continue to the condition of the selector which would cause false to be returned correctly.

Alternatively, we should consider removing the 400 response from the autosaves controller when there are no changes to the autosave, instead treating it as though it were a successful save.

This would arguably be a needless request (a noop), but a preview link could be pulled from its successful response and the user redirected as expected.

Additional context

Part of ongoing struggles with autosave partly addressed in #7130 and relevant Trac ticket.