REST API: Introduce batch controller

[TimothyBJacobs]

Description

This PR introduces a batch controller at /__experimental/batch. It includes support for a validation mode called require-all-validate that necessitates that each request pass validation before it is dispatched. This functionality requires the latest trunk. For users not on trunk, a simpler version of batching is implemented.

For example:

POST /__experimental/batch
{
	"validation": "require-all-validate",
	"requests": [
		{
			"path": "/__experimental/menu-items",
			"body": {
				"title": "Hello Moon",
				"content": "From the world",
				"type": "custom",
				"menus": 3,
				"url": "#"
			}
		},
		{
			"path": "/__experimental/menu-items",
			"body": {
				"title": "Hello World",
				"content": "From the moon",
				"type": "custom",
				"menus": 3,
				"url": "#",
				"target": "invalid"
			}
		}
	]
}

{
  "failed": "validation",
  "responses": [
    null,
    {
      "body": {
        "code": "rest_invalid_param",
        "message": "Invalid parameter(s): target",
        "data": {
          "status": 400,
          "params": {
            "target": "target is not one of _blank, ."
          }
        }
      },
      "status": 400,
      "headers": []
    }
  ]
}

See #24907, Trac#50244.

How has this been tested?

I've done manual testing of the endpoint and added some basic tests to start. I believe tests will be temporarily failing because of the changes required to the REST API server.

Types of changes

New feature

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR. <!-- React Native mobile Gutenberg guidelines: https://github.com/WordPress/gutenberg/blob/master/docs/contributors/native-mobile.md -→

[TimothyBJacobs]

PHPUnit is now passing. Before merge I'd like to expand allow_batch to indicate whether require-all-validate is supported.

Another thing to consider is a way to indicate that permission checks should be called before request validation happens. Right now Core calls permission checks after request validation which complicates things if verifying whether data is valid could wind up exposing sensitive data.

[adamziel]

Nitpick: $batch_request -> $single_request

[TimothyBJacobs]

Good call, fixed in 47edcf6.

[adamziel]

I understand why this code had to be copied and pasted, still I would love to get rid of it (maybe not in this PR). Maybe by updating WP_REST_Posts_Controller::register_routes() to accept an optional $allow_batch=false argument? We could also add a filter to register_rest_route.

[TimothyBJacobs]

Yeah its really not great. My current thinking is we'll just make all posts controllers opt in to batching when we do the Core merge.

[adamziel]

It would be good to test if allow_batch opt-in works - I don't think any test case actually sets it at the moment.

[TimothyBJacobs]

Isn't that covered in test_batch_requires_allow_batch_opt_in?

[adamziel]

It seems like it tests the case where allow_batch is not set, but I don't see any test that actually sets allow_batch to true - maybe I'm missing something. Is it because of the core patch / versioning thing? @TimothyBJacobs

[adamziel]

I left a few notes, it looks great overall @TimothyBJacobs ! I would still like to address this comment somehow, but it seems beyond the scope of this PR. I think it's pretty close, awesome work!

[TimothyBJacobs]

Thanks for the review @adamziel!

Regarding the comment on the earlier PR, I've left some discussion about that on #23474. I agree we can address that in a separate PR.

[adamziel]

We should update @since annotations to say 9.2.0, but that's a detail. It seems like a great first version. Let's get it in and iterate where needed. Great job @TimothyBJacobs !

[adamziel]

E2E test failures seem unrelated to this PR and are similar to failures on recent commits. It seems like TravisCI is having a bad day :-)