Replace synchronous URL validation in editor with async validation

[johnwatkins0]

Summary

Fixes #2069

Before this change, when a user is editing a post, the post's URL is re-validated synchronously on the save_post hook.

After this change, URL revalidation occurs in a separate process after a post has been saved (and on the initial load of the editor).

How it works

• A new REST controller sets up an endpoint that receives a post ID, revalidates that post's URL, and returns validation results. The REST endpoint permission check verifies that the user has dev tools turned on.
• The REST controller uses a context parameter to return only those fields that are used in the editor. The fields are adapted from the amp_validity REST field, which this PR removes. I suggest considering whether some of the fields might be removed entirely (rather than just via REST context), but I think this is a separate issue.
• A React effect hook waits for isSavingPost to go from true to false, and at that time refetches validation results and passes them to the validation data store.

Unfinished

• There is a delay of a second or two between when the post saves and when the data updates in the editor UI. We should potentially display some kind of load state while this is occurring. Otherwise it might be jarring if the user is interacting with the sidebar during save and suddenly items disappear or appear without warning. I'm opening this PR, but we might want to follow up. cc @jwold
• It would be nice to do this: Eliminate synchronous loopback requests in favor of asynchronously re-checking AMP validity #2069 (comment) Done in c6a4f6f

Checklist

• My pull request is addressing an open issue (please create one otherwise).
• My code is tested and passes existing tests.
• My code follows the Engineering Guidelines (updates are often made to the guidelines, check it out periodically).

[codecov]

Codecov Report

Merging #5741 (b231ed7) into develop (113caed) will increase coverage by 0.19%.
The diff coverage is 92.69%.

@@              Coverage Diff              @@
##             develop    #5741      +/-   ##
=============================================
+ Coverage      74.98%   75.17%   +0.19%     
- Complexity      5679     5682       +3     
=============================================
  Files            213      214       +1     
  Lines          17059    17195     +136     
=============================================
+ Hits           12791    12927     +136     
  Misses          4268     4268              

Flag	Coverage Δ	Complexity Δ
javascript	79.44% <96.49%> (+4.31%)	0.00 <0.00> (ø)
php	75.01% <88.57%> (+0.03%)	0.00 <20.00> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ	Complexity Δ
assets/src/block-editor/helpers/index.js	39.28% <ø> (+11.42%)	0.00 <0.00> (ø)
assets/src/block-validation/error/error-content.js	93.54% <ø> (ø)	0.00 <0.00> (ø)
...c/block-validation/error/get-error-source-title.js	93.75% <ø> (ø)	0.00 <0.00> (ø)
src/AmpWpPlugin.php	100.00% <ø> (ø)	8.00 <0.00> (ø)
includes/cli/class-amp-cli-validation-command.php	18.51% <20.00%> (ø)	33.00 <0.00> (+1.00)
...cludes/validation/class-amp-validation-manager.php	81.52% <50.00%> (-0.84%)	309.00 <0.00> (-10.00)
...k-validation/use-validation-error-state-updates.js	84.50% <91.66%> (-9.25%)	0.00 <0.00> (ø)
src/Validation/URLValidationRESTController.php	92.39% <92.39%> (ø)	18.00 <18.00> (?)
assets/src/block-validation/error/index.js	100.00% <100.00%> (ø)	0.00 <0.00> (ø)
assets/src/block-validation/store.js	100.00% <100.00%> (ø)	0.00 <0.00> (ø)
... and 9 more

[github-actions]

Plugin builds for 79751f5 are ready 🛎️!

• Download development build
• Download production build

[johnwatkins0]

Added these unrelated tests to make up for a reduction in JS test coverage percentage, which was causing a ❌

[westonruter]

It's so close!

[westonruter]

I realized we would do well to validate these parameters.

1. Ensure the id and preview_id are positive integers which refer to an actual post.
2. Ensure the preview_nonce is sanitized.

[delawski]

This has been addressed in 669fdce.

Note that we don't have to manually check if preview_id is a positive integer since – as far as I understand and confirmed in tests – it's something done by the REST controller itself. This is why the only thing I've added is a validate_callback that checks if a post exists. With this, it seems the endpoint returns errors as expected:

String:

Negative number:

Inexistent post:

Also, the preview_nonce is now verified in a similar way as Core does in _show_post_preview()

[delawski]

While working on this I realized there's no error handling in our UI (editor sidebar).

I'd say it's not mission-critical, but something we should definitely look into shortly. How about adding error reporting in the follow-up PR #5929 I've already started?

@jwold Having your input on this would be much appreciated.

[westonruter]

Yes, showing the any error resulting from validation can be incorporated into #5929.

[jwold]

Agreed. Will followup on #5929

[delawski]

@westonruter I think all your points have been addressed. Recheck and let me know if you find anything else.

[westonruter]

@pierlon When you can add your review, please do. Then @delawski can address anything that arises as part of #5929 or in another PR.

[adamsilverstein]

Fantastic! 🎉