Create validation constraint for ComponentTreeStructure

Postponing on #3455728: FieldType: Support storing component *trees* instead of *lists*

re #12

1. 1. What if there is a tree of 3 levels deep, and the first level is valid (i.e. all UUIDs under the root also have top-level keys), and the third level is valid, but the second is not? (i.e. a child of the first level does not have its UUID does not exist as a top-level key).

   and

   👆 these are edge cases that I described succinctly in the issue summary as any top-level UUID appears as a UUID in a _parent branch/tree_(except its own branch)

   I don't think this first case is actually what is described in the summary but rather the inverse(unless we are still not talking about the same of constructing the tree from the storage)

   (i.e. all UUIDs under the root also have top-level keys)

   UUIDs under the root should not need to have top-level keys, some will but components without slots should not need any other information in the tree. I confirmed with Jesse Baker that Components are not required to have slots.

   (i.e. a child of the first level does not have its UUID does not exist as a top-level key).

   There is a typo here I think but again I think a child of the first level should not be required to exist as top level key because the child of the first level might not have a slot that needs representing in the tree.

   So I think this tree would valid but it does NOT pass your suggested validation

   [
     "ROOT_UUID" => [
         [ "uuid" => "UUID-IN-ROOT-NOT-TOP-LEVEL" , "component" => "component-with-no-slots" ] , 
         [ "uuid" => "UUID-IN-ROOT-AT-TOP-LEVEL" , "component" => "component-with-slots" ] , 
     ],
     "UUID-IN-ROOT-AT-TOP-LEVEL" => [
       'firstCol' => [
           [ "uuid" => "UUID-UNDER-1ST-LEVEL-NOT-AT-TOP-LEVEL" , "component" => "component-with-no-slots" ] , 
           [ "uuid" => "UUID-UNDER-1ST-LEVEL-ALSO-TOP-LEVEL" , "component" => "component-with-slots" ] , 
       ]
        
     ],
     "UUID-UNDER-1ST-LEVEL-ALSO-TOP-LEVEL"  => [
         'firstCol' => [
              [ "uuid" => "UUID-UNDER-2ND-LEVEL" , "component" => "component-with-no-slots" ] , 
              [ "uuid" => "UUID-UNDER-2ND-LEVEL" , "component" => "component-with-no-slots" ] , 
        ]
       
     ]
   ]
   

   Sorry for the weird naming basically I thought "component-with-no-slots" will be dead-end in the tree and that is by design.

   I have updated the test cases to use either "component" => "component-no-slots" or "component" => "component-slots" to make this clearer.

2. "dangling" aka leftover top-level keys, for components that have been removed. These would effectively be dead weight that continues to exist, taking up storage space while not being visible!

   I think that is what this existing case is catching

   'INVALID: valid tree, with unknown top level' => [
           [
             ComponentTreeStructure::ROOT_UUID => [["uuid" => "uuid-in-root-only", "component" => "component-no-slots"]],
             "uuid-unknown-top-level" => [["uuid" => "uuid-under-top-level", "component" => "component-no-slots"]],
           ],
           ['The UUID <em class="placeholder">uuid-unknown-top-level</em> is not in the tree.'],
         ],
   

   but I have expanded the tree for the case to this

   'INVALID: valid tree, with unknown top level' => [
           [
             ComponentTreeStructure::ROOT_UUID => [
               ["uuid" => "uuid-in-root-only", "component" => "component-no-slots"],
               ["uuid" => "uuid-in-root-and-top-level", "component" => "component-slots"],
             ],
             "uuid-in-root-and-top-level" => [
               "slot1" => [
                 ["uuid" => "uuid-1st-tier-top-level", "component" => "component-slots"],
               ],
             ],
             "uuid-1st-tier-top-level" => [
               "slot1" => [
                 ["uuid" => "uuid-under-1st-tier", "component" => "component-no-slots"],
               ],
             ],
             "uuid-unknown-top-level" => [
               "slot1" => [
                 ["uuid" => "uuid-under-top-level", "component" => "component-no-slots"],
               ],
             ],
           ],
           ['The UUID <em class="placeholder">uuid-unknown-top-level</em> is not in the tree.'],
         ],
   

3. I fixed some of the test cases that were not nested correctly.
4. RE: Do we want to add validation that if component has slots it should have top level key? My guess is not because that would require use to load the actual component config and also maybe some have optional slots but just putting this out there we don't validate this.

5. Can you add a failing test case to \Drupal\Tests\experience_builder\Kernel\Config\DefaultFieldValueTest that triggers a failure for this new constraint for a config-defined component tree?

   Yes, will do this, but not done yet.

   Should we also add the test cases to ComponentTreeItemTest::testInvalidField() to make it sure it triggers for field instances? Right now they use the same helper function, ComponentTreeTestTrait::getComponentTreeTestCases() to provide test cases so we test the same cases in both places

6. I think the test cases would be much simpler to read if they weren't defined as JSON strings, but as json_encode([ … stuff … ]) instead.

   Agreed, fixed

Leaving assigned to myself to do the remaining items but I need confirmation from @Wim Leers that I am right about 1)

@Wim Leers I am working on this part now

slots of every component: the stored slot names (firstColumn and secondColumn in the example at #3455728: FieldType: Support storing component *trees* instead of *lists*) MUST be actually existing slot names for this particular component instance.

I haven't actually dealt with this part of the module at all. Any tips here. How do I load a component from an id? Is this always config component as defined by \Drupal\experience_builder\Entity\Component? there is no class comment so hard to tell. Or could this any sdc component. I have loaded a Component config entity but also there I can't see slot info there.

@Wim Leers assigning back to you for questions on #14. If you have pointers for #15 that would be great(otherwise when I get back this issue I will keep looking)

@Wim Leers sorry for further confusion

but originally in #14 I typed

So I think this tree would valid but it does pass your suggested validation

But meant this.

So I think this tree would valid but it does NOT pass your suggested validation

You responded to this in #17 so wanted to called that out.

I edited #14

re #19

The correction in #18 I was referring to was actually for #14.1

not #14.2

@Wim Leers I changed this to use symfony/validator constraints. I think this is better.

I still need to add some test cases for missing keys and type errors but this logic should already be covered by the constraints.

So I have still have work on it. If you want to just wait until I am done, I can just continue working on it. But if you want to look at the approach feel free

@Wim Leers see MR comments