[Feature widgets screen] a preload_path filter is missing

[manooweb]

Description

In the block editor use for post we are able to filter the $preload_paths variable.
See https://github.com/WordPress/WordPress/blob/5.6/wp-admin/edit-form-blocks.php#L70-L83

It is usefull:

• to add our own paths to take advantage of the prelaoding process and to retrieve some of our datas to build the UI as soon as possible without making a REST API call.
• to be able to add the same parameter we're injecting with the use of apiFetch.use middleware not to trigger a new REST API request. For example, I think to the language code for our need.

It seems that this kind of filter doesn't exist yet in for the new widget screen nor for the FSE.
See
https://github.com/WordPress/gutenberg/blob/v9.8.3/lib/widgets-page.php#L57-L66
https://github.com/WordPress/gutenberg/blob/v9.8.3/lib/full-site-editing/edit-site-page.php#L120-L132

Expected behaviour

Have the same kind of preload_path filter than for the block editor.

[manooweb]

I saw I forgot the navigation editor where nothing is implemented
See https://github.com/WordPress/gutenberg/blob/master/lib/navigation-page.php#L30-L51

I will complete my PR 😉

[gwwar]

Following up on this, @noisysocks noted that

The goal is to have the new widgets screen support as many of the old filters as is possible but it likely won’t be all of the old filters as there are some irreconcilable differences between the two screens. (https://wordpress.slack.com/archives/C01D71823PB/p1612393996060000)

A documentation issue to help clarify what filters are available in what contexts is being tracked here: #28710

[draganescu]

This looks allright but the widgets screen is currently broken in trunk so testing this change is hard to tell if it breaks anything.

[manooweb]

This looks allright but the widgets screen is currently broken in trunk so testing this change is hard to tell if it breaks anything.

Is it possible to test on the latest stable tag ? 10.1.1 for example