Respect _fields query arg in preloaded requests

[jsnajdr]

Suppose a preloaded request includes a _fields query param that asks that only selected response fields are returned. You can add such a request with a filter:

function add_filtered_index_request( $preload_paths ) {
  array_push( $preload_paths, '/?_fields=home,title' );
  return $preload_paths;
}
add_filter( 'block_editor_rest_api_preload_paths', 'add_filtered_index_request' );

However, you will discover that the _fields param is not respected and all fields are returned.

This is because the rest_preload_api_request doesn't call rest_filter_response_fields on the response object. For other requests this call happens inside the rest_post_dispatch filter, but this filter is not called when preloading responses.

Fixes https://core.trac.wordpress.org/ticket/55213

Suppose a preloaded request includes a _fields query param that asks that only selected response fields are returned. You can add such a request with a filter:
{{{php
function add_filtered_index_request( $preload_paths ) {

array_push( $preload_paths, '/?_fields=home,title' );
return $preload_paths;

}
add_filter( 'block_editor_rest_api_preload_paths', 'add_filtered_index_request' );
}}}
However, you will discover that the _fields param is not respected and all fields are returned.

This is because the rest_preload_api_request doesn't call rest_filter_response_fields on the response object. For other requests this call happens inside the rest_post_dispatch filter, but this filter is not called when preloading responses.

This patch adds the rest_post_dispatch filter call after every preloaded response. This filter also calls the rest_send_allow_header function to add the Allow header, so we can also remove an explicit call when handling an OPTIONS request.

Calling the rest_post_dispatch filter should be perfectly fine because it's already called in all similar circumstances:

• when serving a normal REST request in WP_REST_Server::serve_request
• when performing a batched request in WP_REST_Server::serve_batch_request_v1
• when embedding links in WP_REST_Server::embed_links

One extra effect of this patch is that preloaded responses for GET requests will also include headers, while previously they would only include body, and headers would be present only for OPTIONS responses. Before:

{
  '/': {
    body: { home, title }
  },
  'OPTIONS': {
    '/': {
      body: { home, title },
      headers: { Allow }
    }
  }
}

After:

{
  '/': {
    body: { home, title },
    headers: { Allow }
  },
  'OPTIONS': {
    '/': {
      body: { home, title },
      headers: { Allow }
    }
  }
}

Including these headers is a good and desirable thing because it allows us to get rid of redundant OPTIONS request where we already have GET response. The GET response would now already contain the desired info about permissions. See also this discussion on a Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/38901#issuecomment-1044340843

In principle this patch is similar to what @TimothyBJacobs did some time ago for embeds: https://core.trac.wordpress.org/ticket/51722

[costdev]

With 6.0 Beta 1 released yesterday, I'm moving this ticket to the 6.1 milestone.

[gziolo]

In 53217:

REST API: Respect _fields query arg in preloaded requests

Ensures that preloaded request can include a _fields query param that asks that only selected response fields are returned.

Props jsnajdr, timothyblynjacobs.
Fixes #55213.
See #55567.

Committed with https://core.trac.wordpress.org/changeset/53217.