Block Editor: Remove bundled block patterns and support the patterns directory.

[youknowriad]

In this PR ​https://github.com/WordPress/gutenberg/pull/28800 the bundled core block patterns have been moved to the block directory and are now fetched from the REST API.

We need to make the same changes to Core.

This ports over the pattern-directory API endpoint from Gutenberg trunk. This was added in ​https://github.com/WordPress/gutenberg/pull/28800 & ​https://github.com/WordPress/gutenberg/pull/26578.

I've removed most of the default patterns, and hooked up the Pattern Directory API to return the patterns marked "Core" from ​https://wordpress.org/patterns/.

This remote loading checks for core-block-patterns theme support and adds a new filter, should_load_remote_block_patterns. If core-block-patterns theme support is removed, it will disable all core patterns including remote patterns. If should_load_remote_block_patterns is filtered to return false, the core query blocks will be registered, but the remote request won't happen.

This is done without the blockTypes support, since ​https://github.com/WordPress/gutenberg/pull/32113 is still in progress. If I understand the process correctly, that can be done during feature-freeze?

Trac ticket: https://core.trac.wordpress.org/ticket/53246

I started looking into the failing test here. It looks like if I comment out the added current_screen filter, the tests pass as expected. Also worth noting that the test passes when running only one specific group.

I have to step away for a bit, but I'll circle back when I return to continue looking into the issue.

These errors are occurring in rest_preload_api_request which is what is causing the preload data to be empty, and causing the test to fail.

WP_REST_Response Object
(
    [links:protected] => Array
        (
        )

    [matched_route:protected] => 
    [matched_handler:protected] => 
    [data] => Array
        (
            [code] => rest_no_route
            [message] => No route was found matching the URL and request method.
            [data] => Array
                (
                    [status] => 404
                )

        )

    [headers] => Array
        (
        )

    [status] => 404
)
WP_REST_Response Object
(
    [links:protected] => Array
        (
        )

    [matched_route:protected] => 
    [matched_handler:protected] => 
    [data] => Array
        (
            [code] => rest_no_route
            [message] => No route was found matching the URL and request method.
            [data] => Array
                (
                    [status] => 404
                )

        )

    [headers] => Array
        (
        )

    [status] => 404
)

Not sure why those routes don't appear to be registered yet. It may be that the REST Server initialization caused by the _load_remote_block_patterns is too early somehow?

I pushed a fix. Ideally we'd have some way of detecting when the REST API server needs to be registered built in to the base test class, but alas.

Thanks for tracking that down, @TimothyBJacobs!

[ryelle]

In 51021:

Block Editor: Add support for the pattern directory.

Add an endpoint for fetching block patterns from WordPress.org, and load the block patterns from this new API. Remove the block patterns that have already been moved to WordPress.org/patterns.

Props ryelle, iandunn, youknowriad, timothyblynjacobs.
Fixes #53246.

Committed this first pass in r51021.

[desrosj]

In 51093:

Coding Standards: Apply an alignment fix.

Follow up to [51021].

See #53246.

[desrosj]

In 51133:

Upgrade/Install: Update the $_old_files list for 5.8.

Follow up to [50761], [50794], [51021].
Props kapilpaul, desrosj.
See #52991, #52846, #53246.
Fixes #53367.