Replace unstable__bootstrapServerSideBlockDefinitions with call to block type REST API

[spacedmonkey]

Part of https://github.com/WordPress/gutenberg/issues/41236.

Currently in WordPress core the follow lines appear.

// Preload server-registered block schemas.
wp_add_inline_script(
    'wp-blocks',
    'wp.blocks.unstable__bootstrapServerSideBlockDefinitions(' . wp_json_encode( get_block_editor_server_block_settings() ) . ');'
);

This was a workaround added in WordPress 5.0. Now that the block types endpoint was added in https://github.com/WordPress/gutenberg/pull/21065 , this should be used as the "point of truth" for block definitions.

Describe the solution you'd like The block types api should be preloaded on the page by adding it to this array.

[aduth]

This would be a good application of the new block types endpoint. 👍

As far as implementation, it's unclear to me in how @wordpress/blocks remains rather agnostic to the source of block type definitions whether it should be the point where the implementation occurs.

Instead, it may be something that ought to occur elsewhere in the editor initialization where this sort of integration would be appropriate.

For example, one of:

• @wordpress/block-library, where registration of core blocks already occurs.
• @wordpress/editor or @wordpress/edit-post, which represent the top-level application components for a post editor and the "Edit Post" screen respectively.
• An inline script? Probably unadvisable.

In any case, the implementation should use the new REST API endpoint, in combination with @wordpress/api-fetch (see mentioned preloading in original comment) and possibly (ideally?) as a reusable data entity from @wordpress/core-data.

[spacedmonkey]

@gziolo @Mamaduka Any chance we could get eyes on this ticket?

[Mamaduka]

@spacedmonkey, chatted briefly with @gziolo about this ticket and https://github.com/WordPress/wordpress-develop/pull/5718#issuecomment-1845361155. Agreed that the source of the truth should be REST API for the editors, whenever possible.

@kt-12 mentioned that some information is missing for dynamic blocks returned via API.

It would also be nice to see performance metrics when preloading data via block_editor_rest_api_preload vs. get_block_editor_server_block_settings.

cc @@joemcgill