[SPIKE] Prove that it's possible to apply block settings update paths to stored XB component trees

Can we use 📌 Introduce unit test coverage for both ComponentSource plugins (Block + SDC) Active to use xb_test_block as blocks to update?

Plan articulated → at 🌱 [META] Production-ready ComponentSource plugins Active .

1. We need to write an update path + update path test that does the exact same thing for a search block stored in an XB component tree.

Are we thinking here that we need block implementations to provide separate code paths to update XB blocks? If so, what happens if a contrib author decides not to do that? Or, who takes responsibility for core block updates, if core does not depend on XB?

On the other hand, I am not sure if this will work, but I wonder if we can do this without contrib maintainers needing to do anything at all! Block updates are generally written like this:

function search_post_update_block_with_empty_page_id(&$sandbox = []) {
  $config_entity_updater = \Drupal::classResolver(ConfigEntityUpdater::class);
  $config_entity_updater->update($sandbox, 'block', function (BlockInterface $block): bool {
...

Can we decorate ConfigEntityUpdater so as well as updating config entities, we additionally reconstruct config entities for blocks in XB content, and allow the closure to make changes to them in the same way? The closure is not responsible for saving the config entity - so because these won't be real config entities, we never need to directly save them; we can just extract the settings (or whatever else might have changed?) and put them back into the XB storage.

Will discuss #8 + #9 tomorrow with @longwave :)