Remove ComponentTreeItemList::ROOT_UUID from hydration and client-to-server conversion

It seems like this should be stable blocker decide at least if we want to do this. If we do it is probably better before stable otherwise I think we would have to write an update hook that would update all content entities to use the new structure.

This also relates to #3455629: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model: once content type template exists, the following scenario can occur:

1. the XB content type template for "article nodes" has 3 subtrees that are unlocked, i.e. in which content creators can do whatever they want
2. that means the XB field for each article node won't store a single tree anymore (under the root UUID), but 0–3 trees!

ContentTemplate config entities now exist.

#3517845: Content templates, part 3a: allow content templates to define exposed slots is in, and #3519352: Content templates, part 3b: store exposed slot subtrees on individual entities is being worked on. @phenaproxima, any thoughts on this given you're actively working on #3519352? 😄

Well, at the moment, #3519352: Content templates, part 3b: store exposed slot subtrees on individual entities uses the root UUID to know what components in a subtree need to be injected directly into an exposed slot, and which components are just added to the main tree.

Having said that, though, what would the tree structure look like if we made this change (how would it represent infinite nesting)? That would help me understand any knock-on effects for exposed slots.

Back to Wim for answers. :)

#3468272: Store the ComponentTreeStructure field property one row per component instance will likely implicitly address this.

IOW: this will likely be closed. Let's hope. 🤞

When this issue was opened, every component tree in XB was self-contained. But with #3455629: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model getting implemented, that will change:

• for content entities whose content entity type + bundle has a ContentTemplate, it's possible that each individual content entity does NOT define the full component tree, but only bonsai trees (see #3519352: Content templates, part 3b: store exposed slot subtrees on individual entities) to populate the ContentTemplate's exposed slots — aka the "islands of freedom", but the root of the tree would be the same for all content entities.
• IOW: the root of the tree would always originate from the ContentTemplate, and each content entity would not store one component tree (starting at the root), but multiple bonsai trees (staring at slot of a component instance in the ContentTemplate's component tree whose slot was explicitly exposed).

In that world, to be able to distinguish where the root begins and ends. For a moment, I thought while reviewing #3468272's MR that we'd need to keep the root UUID. But thanks to ValidParentAndSlotConstraintValidator's logic in that MR, I think we don't! Would be good to have @larowlan confirm :)

I think the front-end is still using it, so we will need to handle that at the same time, but yes, the path to removing it is clearer after that

👍

(Although I don't see how the front end using it is relevant: the client-side data model already is very different from the server-side one. It'd be fine for the client to continue to have such a root UUID. This issue is solely about the server-side data model.)

Reviewing #3468272: Store the ComponentTreeStructure field property one row per component instance right now, it 100% certainly addresses this! 🥳

Actually — I'm kinda wrong in my prior comment!

That MR mostly addressed this:

• the root UUID is no longer used in storage (neither for component trees stored in a XB field on a content entity, nor in component trees in config entities) — this is the critical stable-blocking part @tedbow pointed out in #2 👍
• but it is still used when A) hydrating the tree (ComponentTreeItemList::constructDepthFirstGraph()) and hence when rendering, B) when performing the client-to-server conversion

We should still remove it, but it's actually only used internally now; so refactoring it away is essentially a purely internal change 🥳

So: reducing priority, retitling, rescoping.