Remove @wordpress/api-fetch usage from the block editor module

[youknowriad]

Related #14043

The idea is that the block editor module is independent from WordPress or Rest APIs, it should be usable in any context.

In this PR, I'm removing the apiFetch usage by providing a fetchLinkSuggestions setting to the editor settings. So by default URL inputs in any block editor will work properly but without any suggestions, if you want to enable suggestions, you provide a function returning a promise with the suggestions.

Testing instructions

• Check that the adding links work properly
• Check that you have post/pages suggestions when typing in the Url Input.

[gziolo]

Everything works properly with all those changes applied.

I like that fetchLinkSuggestions is now passed as a prop to the component. It's also acceptable to put it inside block editor setting for the time being as an experimental feature __experimentalFetchLinkSuggestions.

At the same time, I want to make sure we have a follow-up issue opened which will try to find a long-term solution for extensibility in this area. We have 3 experimental settings which aren't really setting value:

• __experimentalFetchLinkSuggestions
• __experimentalMediaUpload
• __experimentalReusableBlocks

All 3 items are closer to data actions which could be implemented internally with controls maybe. Another way of approaching this complex use case would be through context API (maybe with React hooks?).

[youknowriad]

I feel having callbacks in settings is fine. the two first ones mentionned here are experimental because I'd prefer to have some time to validate the proposal but they still feel like block editor settings for me.

The last one is ideally removed but I'm not sure at this point if it's possible or not.

[aduth]

Similarly, without a deep review, this looked good on the surface. For future exploration, I'd wondered if it could be something along the lines of what was explored previously in #9210 in allowing custom resolver behavior to be implemented by the extending context. I guess the idea of "the editor component" implementing a resolver is non-conventional, but on the consuming end, it seems nice the idea of a fetchLinkSuggestions selector which is stubbed by default as an "abstract" selector.

[gziolo]

I guess the idea of "the editor component" implementing a resolver is non-conventional, but on the consuming end, it seems nice the idea of a fetchLinkSuggestions selector which is stubbed by default as an "abstract" selector.

Thinking a bit more about this idea, I'm coming to the conclusion that this might be less flexible than using context API or the existing BlockEditorProvider component. In particular, this could be super handy in the case of nested editors. Reusable blocks are an immediate example that comes to my mind.