Twenty Twenty-One: Efficiency refactor of excerpt-generation with Block Processor.

[dmsnell]

Refactors twenty_twenty_one_print_first_instance_of_block() to rely on WP_Block_Processor where available. This brings an uplift in efficiency in two separate ways:

• The Block Parser only needs to parse as far into a document as it needs to read, and lazily parses block attributes. This can result in a dramatic reduction in memory overhead as long posts do not need to be fully parsed and temporarily stored in memory, just to be ignored.
• By doing less work the Block Processor is able to stop its processing and move on, while parse_blocks() has to pause the world while it builds the full block tree.

This is not supposed to change any existing behavior, though it does rearrange some of the code from the legacy approach to harmonize with the logic in the refactor. While separate functions in the refactor would be more testable, this function lacks testing and the combined logic may be simpler to maintain over time. Given that the minimum supported WordPress version will remain at 5.6, the check for the existence of the class will have to stay, and grouping common logic in a single function will be less effort than maintaining those potential changes across two functions.

Trac ticket: Core-64482
See: Core-61401
See: ~#9105~, ~#9841~, (~#9842~ -> #10291), ~#9843~ -> #10292

Refactors the excerpt-generating functionality in twentytwentyone to use WP_Block_Processor and avoid loading entire posts into memory. This streaming approach scans through the post contents and only parses as much as is required to provide the requested blocks.

@sabernhardt in 9d100de I made the following changes:

• Unified the two functions, largely because of the mention that the old one will never go away via minimum-version-bump. These are less independently testable, but I think automated testing is already lost on this anyway 🤷‍♂️.
• Rearranged some code from the legacy function to mirror the new code. This change could have been done independently but it makes more sense to me to do it for the symmetry with the new approach. I’m happy to remove this change if it’s unwanted (same goes for my little update to use array_shift(); that’s slightly more memory efficient because it frees up the parsed blocks as they are processed or rendered but not essential. it _can_ make a substantial impact for very large posts and for posts with very deep cascades of nested blocks though - see also #8999)

Further, I have created the Trac ticket in the bundled-themes component and linked it with this PR.

Thanks a million for your help!

I'm not well versed in development practices around these Core themes.

I have reviewed the changes here and they seem sensible.
I did some manual testing on a personal site with this change on trunk and this change applied to the 6.8 branch. They appear to have the same behavior and no errors.