This pull request seeks to update the block editor's withPersistentBlockChange to consider RECEIVE_BLOCKS as a non-persistent change. This is intended to mimic the equivalent behavior which had existed prior to #13088, where the block editor dispatches a RECEIVE_BLOCKS action when receiving reusable blocks. The data for reusable blocks is kept alongside other blocks data, though changes to this data should not be interpreted as the result of a user interaction.

It's hoped that these changes should bring some improved stability "Undo" end-to-end tests, where on a hunch I suspect the failures may be a result of delayed responses from reusable blocks fetch which occurs upon focusing a paragraph block (from the blocks autocomplete inserter). (Related Slack conversation)

As noted at #13088 (comment) , the separation of reusable blocks across the editor and block-editor modules does not seem cohesive. As described above, the blocks data for reusable blocks is kept in the block editor's state.blocks state, but is cross-referenced on the editor module's reusableBlocks state.