REST API: introduce block-editor context

[kadamwhite]

The block editor does not make use of rendered content, and rendering content for complex posts with a large quantity of dynamic blocks can take a non-trivial amount of time. The REST API maintainers and Gutenberg developers have previously discussed the need to be able to "skip" rendering of the content if it is not required.

In [46184] we introduced the ability to provide an explicit list of nested fields to include. Specifying _fields=content.raw without mentioning rendered now causes the posts controller to skip computation of the rendered field, as it has not been requested. Unfortunately, this approach requires a developer to provide a comprehensive list of all fields they _do_ wish to include in the response, and cannot easily be used to specifically exclude one field. Because block editor developers may depend on registered rest fields or other additional properties, it is infeasible to have the block editor request "all but the rendered content" using this interface.

A slack conversation (​https://wordpress.slack.com/archives/C02RQC26G/p1574361923322500) with @aduth and @timothyblynjacobs addressed this problem and discussed two separate options, either providing an _omit_fields parameter to complement _fields and permit specific exclusions, or alternatively to introduce a new block-editor context that does everything that edit does except render content.

This trac ticket is intended to move that discussion forward and aim towards introducing a solution that can be used to speed up response times within the block editor.

[kadamwhite]

@TimothyBlynJacobs asked during an in-person working session whether this new context would also be an opportunity to introduce a different permissions model that has been previously requested by the Gutenberg leads, where the REST API would return as many properties of a response as it could given the current permissions, rather than failing an entire response because one field is inaccessible. At the moment @kadamwhite thinks it's best to treat that as a separate discussion.

[davidbaumwald]

@kadamwhite Is this still doable for 5.4 with Beta 1 approaching in a couple of days?

[kadamwhite]

@davidbaumwald I'm disappointed in myself that I haven't had time to go for this, but no, the deadline's too close to do this correctly. Punting to 5.5.

[TimothyBlynJacobs]

Punting to 5.6 This still needs coordination with the Gutenberg team to determine what fields are appropriate.

[TimothyBlynJacobs]

Punting to future release. This hasn't garnered much interest from the Gutenberg team recently.