Improve performance for command and selection changes

[jonathonherbert]

What does this change?

We recently had a large article — 7000+ words and 242 elements, id 673f39b58f083ae557dd22af — which was slow to load and edit in production.

Using that article as a test case, this PR improves the performance of the elements plugin in two ways:

• f62abf6: only calculate whether commands are valid once per transaction, storing the result in a plugin and using that to determine whether consumers need to rerender. Thanks @KaliedaRik for suggesting this approach as we paired to figure out what was slow!
• 7076cba: only update elements on selection change if the selection concerns them (i.e. the selection moves within the node, or moves in or out of the node)

To help measure performance when profiling these changes, e857a1a adds a flag to disable performance-heavy features, which is useful for removing noise from serialisation, collab and dev tools code when profiling.

The table below gives the profiler script time for 30 keystrokes with the article above loaded in the demo page, with the above flag disabled. Tested on Chrome 131.0.6778.205 a 14-inch Macbook Pro, M1 Max, 2021:

Iteration	40dded8	f62abf6	7076cba
1	2224	1353	555
2	2230	1403	554
3	2381	1378	569
Average	2278.333333	1378	559.3333333
ms per keystroke	75.94444444	45.93333333	18.64444444

About 4x faster.

How to test

• Reviewing commit-by-commit should make the changes as clear as possible. I'm really happy to pair on reviewing anything that isn't clear.
• This PR adds unit tests for the selection logic, and updates our rerender tests in https://github.com/guardian/prosemirror-elements/blob/main/src/plugin/__tests__/plugin.spec.tsx to account for the new behaviour. They should pass. Existing integration tests test element wrapper movement.
• Perhaps have a play with that large document on main and this branch, by copying and pasting the content from our CMS to the editor playground (yarn start.) Can you feel the difference? You can also test in Composer following the instructions in the readme — I've included examples of both in GIFs here:

Location	Before	After
Sandbox
Composer

How can we measure success?

Less pain editing large articles.

Is there anything more we can do?

On modern hardward, large articles with large numbers of elements like the above are still slow to load (something this PR does not attempt to address), and still have appreciable jank.

It looks like iterating over decorations, which we use to ensure nodeViews always update, takes up a fair few cycles, too. That might be another good place to start looking for performance improvements.

Loading improvements look like they're connecting to rendering. A few strategies we could try:

• Optimise the rendering of individual components.
• Optimise the rendering of components generally, perhaps by avoiding a React root per-element and mounting elements in portals instead.
• Implement a strategy for virtualising element rendering, so offscreen elements are not rendered until they're needed.