To support site templates, ensure component definitions are rebuilt while applying recipes

LGTM!

wim leers → credited larowlan → .

1. I don't yet understand why merely retrieving definitions is sufficient (and nor did @larowlan) — see MR comment for details. Can you articulate why? 🙏
2. This must be generalized to not hardcode assumptions for the 2 plugin-powered ComponentSources we have today (block + sdc).

   See the MR comment + #3526045-7: Consider renaming ComponentSource plugins to ComponentType → for how this could be achieved.

I don't yet understand why merely retrieving definitions is sufficient (and nor did @larowlan) — see MR comment for details. Can you articulate why?

Retrieving definitions will regenerate all the component entities if needed (as you know), but you're right that this is setting up a bug if the cache is not empty. So I added an explicit cache clear.

This must be generalized to not hardcode assumptions for the 2 plugin-powered ComponentSources we have today (block + sdc).

I changed the subscriber to a service collector for CachedDiscoveryInterface. That still ties it to plugins...for now. But using a service collector gives us some more leeway later, if we add a new interface for component discovery. That will make it easier to refactor. I didn't do it as you suggested in [#16120596-7] because that makes the dependency injection trickier/impossible. Besides, service collection is a well-used pattern in core.

there's some CI fails we likely need to address

Looks like the only one outstanding is in component-operations.cy.js, with the same damn failure that seems to inexplicably haunt every goddamned MR I submit to Experience Builder. :) I don't see how the changes here could be affecting that, since the recipe event subscriber only does anything if a recipe is applied. I'm not really sure how to approach fixing it, since I'm not sure the cause of it was ever discovered the previous times I encountered it.

That last commit is 🤩👏