Add Entity Update controller

Very much on the right track, but I think in the current state it'll be hard to evolve.

I left a bunch of suggestions that IMHO make this more approachable, and make it easier to iterate on in the future.

WDYT, @tedbow?

A thorough review round 🏓

I think there's some crucial bits that are too rough to get merged here:

1. supports only POST but does not restrict the route to that and appears to support updating an entity. Suggested fixes on MR: rename route + controller to be about saving entity revisions, not entities, then it all makes sense.
2. the validation error response is way too unstructured, even after having incorporated @longwave's feedback. This will make surfacing validation errors on the client side unnecessarily cumbersome. All the right pieces exist already. I pointed to them in my MR comments.
3. The helper methods were constructing various kinds of undocumented arrays of doom. This is implied by your comment at https://git.drupalcode.org/project/experience_builder/-/merge_requests/3.... I pushed a handful of commits that improve that.

Sorry for frustrating you, @tedbow 😬 🙈

Given this is introducing a HTTP API route that accepts arbitrary inputs, we IMHO should not defer precise validation error messages for the UI to follow-up issues: this issue IMHO SHOULD provide the necessary infrastructure to enable folks working on the XB UI to work on validation errors at the same time as they work on saving — because they go hand-in-hand. Validation was already handled … but it was lacking the precision needed for the XB UI to provide a good UX.

@tedbow is right that this resulted in some scope creep. But that's only because I tried to accelerate getting this MR to the point where I am comfortable with it landing (thanks to it being sufficiently complete/not having many follow-ups). Ideally, the changes to ValidComponentTreeConstraintValidator would have happened in a blocking issue/MR (commits https://git.drupalcode.org/project/experience_builder/-/merge_requests/3... + https://git.drupalcode.org/project/experience_builder/-/merge_requests/3...), but for the sake of speed/minimizing overhead, I am personally fine with the scope creep 😇

In particular these two MR threads:

• https://git.drupalcode.org/project/experience_builder/-/merge_requests/3...
• https://git.drupalcode.org/project/experience_builder/-/merge_requests/3...

👏

The two failing test cases are excellent additions! 👍 🙏

Correct me if I'm wrong: AFAICT those new test cases would also have failed before I started making significant changes, right? 🤔

Asymmetric validation of layout/tree vs model/props.

I did already spot the validation asymmetry: model is validated, but tree is not. That was a concern, but I didn't want to hold this back any longer because I believed the infrastructure now had the right shape.

So if I was right, I should be able to:

1. quickly fix the remaining two failures
2. AND reuse all of the existing validation infrastructure

Solution

Thankfully, that is the case:

1. https://git.drupalcode.org/project/experience_builder/-/merge_requests/3... introduces the same pattern for ::clientLayoutToServerTree() as I already added for ::clientModelToServerProps() → fixes add a failing test case for missing component
2. 👆 that did NOT fix add failing test case for missing props — because in HEAD, it's been impossible to send such an invalid value, since this MR introduces the potential for arbitrary inputs, as I described on the MR yesterday: https://git.drupalcode.org/project/experience_builder/-/merge_requests/3.... That's why HEAD has \Drupal\experience_builder\Plugin\DataType\ComponentPropsValues::getComponentPropsSources() throwing an exception when tree + props (in the client-side data model: layout + model) are out of sync.
3. That simply was due to one missing catch in ValidComponentTreeConstraintValidator that I just added in https://git.drupalcode.org/project/experience_builder/-/merge_requests/3...— which was written by yours truly to validate that tree+props together are valid 😊

Conclusion

Overall, thanks to your two new failing test cases, the point I was making during my reviews has actually been confirmed 😅: any API interactions MUST maximally reuse the existing validation constraints.

Put differently: if any gaps are found in the validation, then we MUST NOT write additional logic for the one code path we're working on in an MR, but instead we MUST update the validation constraint validator itself, to ensure it runs always. That is how we achieve consistency across the entire codebase, and how the same concepts are treated the same everywhere, making the codebase easier to reason about.

Oops, wrote my comment in the IS field 🤣🙈

Crediting @larowlan for his review on the MR, which I responded to — I agree.

but I like the changes we use more of the validation logic we already have.

— @tedbow at https://git.drupalcode.org/project/experience_builder/-/merge_requests/3...

Whew! 😮‍💨

Per #30, merging! But apparently this needs to pull in origin/0.x first, so did that, eagerly awaiting test results 🤓

Merged!

Next step: reroll #3487773, because this MR moved some code that that MR was going to remove — see #3487773-7: Get component name from components list not from the component's model. Un-RTBC'd that prioritize this (more complex) MR.