Shared Blocks: Fix editing paragraph blocks

[youknowriad]

closes #7075

Right now editing shared blocks is broken because when we render the Autocomplete component (used in paragraph blocks), we're triggering a "fetch shared blocks" request. This requests is causing the uid of the block attached to the shared block to be regenerated which means the block will rerender (considered as a different block) and the loop continues.

The root cause of the issue is not fixed in this PR, this is a hacky fix will small implications than can land in 3.0 but as a follow-up I'm planning to fix the root issue which is the fact that we have a cycle dependency in our shared blocks state.

sharedBlock.id => block.uid relation
and
block.uid => sharedBlock.id

This cycle is forcing us to regenerate the block attached to the shared block when we fetch them.

[mcsf]

Thanks for the quick fix + proper fix. LGTM.

[mcsf]

Regarding the failing tests: the fact that we now always fetch shared blocks means that RECEIVE_BLOCKS will be dispatched via RECEIVE_SHARED_BLOCKS. As a result, core/editor::editor.past receives a history snapshot and the Undo button becomes enabled because hasEditorUndo( state ) === state.editor.past.length > 0 === true.

This isn't an issue introduced in this PR (nor in the previous PR working on the autocompleter, IMO), but it exposes the root problem: that adding block knowledge (awareness of available shared blocks) to our application (even when said blocks are not impacting the post) is treated as an editor change.

[noisysocks]

Nice hack 👍

[youknowriad]

I updated the hack to avoid the initial "history". It's still hacky though. Let's get this in and see how we can fi the shared blocks root state issue later.