Harden access to validation data

[westonruter]

Summary

By default the amp_validate capability is mapped to manage_options. However, it doesn't have to be. A site could disable access to validation data entirely—even to administrators—using a plugin like:

add_filter(
	'map_meta_cap',
	function ( $caps, $cap ) {
		if ( AMP_Validation_Manager::VALIDATE_CAPABILITY === $cap ) {
			$caps[] = 'do_not_allow';
		}
		return $caps;
	},
	10,
	3
);

If I try doing that, some unexpected things happen for new screens in 2.2:

1. The settings screen throws an error. Site Scan should be omitted entirely.
2. Site Scanning is able to proceed in the Onboarding Wizard. Site Scan step should be skipped.
3. Support screen is accessible. It should not be available.

We need to make sure that if a site is restricting access to any validation data by checking first if the user AMP_Validation_Manager::has_cap().

Checklist

• 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).

[github-actions]

Plugin builds for 6746ec2 are ready 🛎️!

• Download development build
• Download production build

[delawski]

@westonruter In ae702a3 you'll find the most important change – a new scanner status is introduced there, STATUS_SKIPPED. It is set if there's no VALIDATE_NONCE passed from the backend meaning that the current user has no capabilities to do AMP validation.

In e656fbf a minor refactor has been done so that the complexity of the siteScanReducer function is within the predefined limit.

Lastly, in e483fbe new E2E tests have been introduced. Thanks to them we're sure that if a user has no validation capability, Site Scan won't be available on the AMP Settings screen, in the Onboarding Wizard and after plugin activation.

I think it's now ready for your review.

---

As a side note, I think that our context provider trees are becoming pretty big and complex, with various dependencies between providers. I'm thinking of reevaluating this approach and maybe looking into a more systematic solution like React Query that would abstract away data fetching, caching and updating. Since data is stored in a global variable (internally), it can be exposed everywhere in a React app using a set of hooks. This might simplify and decouple the client-side data layer.

[westonruter]

@delawski Thank you for the additional changes! Looks great and now behaves as expected.

[westonruter]

Nit: the list of plugins could be in an array, and then they could be looped over.

[delawski]

Yeah, I was thinking of the same, though there might be some issues when using await inside a loop. Let's take care of that as soon as we need to add another plugin.

[westonruter]

Merging without approval since I'm the one who started this PR. @delawski I'm assuming you approve 😄 If you can sanity check my additional changes that would be great.

[delawski]

The changes (and the PR overall) look good to me 👍

[dhaval-parekh]

QA Passed

After using the plugin with the code given above (in the description).

✅ The "AMP Setting" page is functioning correctly and site scanning is omitted on the page.

✅ Support page, Validated URL and Error Index page is disabled for the user.

✅ On the "Onboarding Wizard" step for site scan is removed.