Block Editor: Partition attributes updates to avoid conflating meta and blocks attributes

[aduth]

Fixes #15739

This pull request seeks to resolve an issue where setting a new meta attribute value in a block can wrongfully displace the text caret selection.

Implementation Notes:

I consider this to be an incomplete but likely sufficient resolution to #15739. The issue occurs because a render of the block's edit occurs synchronously as a result of updateBlockAttributes. At this point in time the meta attributes have not yet updated, so the old value is used (more at #15739 (comment)). Arguably, it is not correct (or at least ineffective) to be calling updateBlockAttributes with new meta values, since the selector to generate a block's attributes will always ignore these (source). To that point, the changes here will avoid calling updateBlockAttributes with meta value updates, and avoid calling it altogether if the only attributes updates are meta value updates. The solution works because updateBlockAttributes is avoided, and thus the problematic intermediate render does not occur.

It is technically incomplete in that if a block were to call setAttributes with a mix of block attributes and meta attributes, a similar issue may occur. It is quite unlikely that a block would be implemented this way.

In any case, I'd like to see some improvements to this sort of "external" sourcing, which would be a larger task than I propose to resolve here. I will aim to submit a formal proposal for how it might work, informed on #15739 and previous issues #4989 and #2759. An inline code comment has been added to reflect this future work.

Testing Instructions:

An existing end-to-end test case has been adapted to reveal the failure from master resolved here. Verify that it passes:

npm run test-e2e packages/e2e-tests/specs/plugins/meta-attribute-block.test.js

Repeat Steps to Reproduce from #15739

[youknowriad]

The behavior of all this setAttributes function seems like something that should be absorbed in the updateBlockAttributes action instead.

As you said, we should ship the bug fix and consider these consolidations separately.

[aduth]

The behavior of all this setAttributes function seems like something that should be absorbed in the updateBlockAttributes action instead.

As you said, we should ship the bug fix and consider these consolidations separately.

Yes, I think so too. One point of clarification / affirmation is that: I don't think the changes here dig us any further into a hole, and in-fact serve more as an implementation which ought to have existed in the first place.