Add a new internal HTTP API for candidate `DynamicPropSource`s to enable a `ContentTemplate` UI

Not too sure what's causing those unrelated test failures!

Hm … me neither, but this seems like yet another case of https://www.drupal.org/project/gitlab_templates being wrong and running contrib module's test suites differently for non-maintainer-pushed commits than for maintainer-pushed commits 😬 (I wish I was kidding!)

Also: you're right, I misjudged, this is not a trivial move. 🙈 Thanks for removing the Novice tag.

But … this issue is novice-like in the sense that you were able to do this without deep XB knowledge! 😄 What do you think would be a more appropriate tag? 😊

Repurposing per #3530907-7: Optimize DynamicPropSource candidate suggestion logic: improves performance of /xb/api/v0/config/component by 80%.

Suggested API route:

experience_builder.api.info.candidate_dynamic_prop_sources:
  path: '/xb/api/v0/info/candidate_dynamic_prop_sources/{entity_data_definition}'
  methods: [GET]
  …

So: /xb/api/v0/info/candidate_dynamic_prop_sources/entity:node:article etc.

Perfect, thanks!

This will be a blocker for the Content Templates UI: #3455629: [PP-1] [META] 7. Content Templates — aka "default layouts" — affects the tree+props data model.

MR 1379 doesn't address the full issue scope, but I understand how that came to be.

That doesn't mean MR 1379 is wrong — we still need it, but it's only the original side of the coin, since #10 the coin gained another sight (metaphor falling apart — it's been a long day 😅.

Having worked on many of the pieces powering FieldForComponentSuggester and the historical creation (#3455975: HTTP API: update /xb-component/{component_id} to list possible prop sources for current entity context) of the test we're refactoring away here, it seemed only reasonable that it was up to me to perform the git+d.o archeology work to bring clarity to the rationale behind what is being tested, and clean it up.

It can be improved further, but it is now sufficiently clear and commented for others to be able to iterate on it further. Merged @isholgueras' MR with my refinements. 👍

Next up: what this issue was rescoped to in #10. I'll get an outline of an MR going.

Pushed up a rough outline: https://git.drupalcode.org/issue/experience_builder-3510896/-/commit/bca....

We'll need to tackle #3523446: Rename `FieldForComponentSuggester` to `PropSourceSuggester` and #3503038: Enable candidate `DynamicPropSource` suggestions for code components: refactor `GeneratedFieldExplicitInputUxComponentSourceBase` and `FieldForComponentSuggester` to need only SDC's ComponentMetadata, not SDC plugin instances too, but there's no need to get blocked on that — it's better to get something rough going to unblock #3518248: [PP-1] Content templates, part 4 (boss battle): create a UI for editing templates :)

🏓 Initial review posted :)

This needs input from #3518248: [PP-1] Content templates, part 4 (boss battle): create a UI for editing templates and especially #3538861: Spike: UI for content templates, to determine what the ideal API response shape would be for the client side.

Almost there: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1... — please confirm, @hooroomoo.

Perfect, I have everything I need now to finish this up :)

I won’t have time to finish this MR today — there’s still a bunch of loose ends to clean up, but it works.

@hooroomoo, please test, and confirm that this is what you want/need! 🙏 😇

You'll get something like:

Thanks to @hooroomoo's test of this together with their PoC, I can now land this with confidence 🥳

Out of scope:

1. making these API responses cacheable — if the need ever arises, we'll do that then
2. code component support is out of scope — we have had #3503038: Enable candidate `DynamicPropSource` suggestions for code components: refactor `GeneratedFieldExplicitInputUxComponentSourceBase` and `FieldForComponentSuggester` to need only SDC's ComponentMetadata, not SDC plugin instances for >6 months now to do exactly that
3. fixing a shape matching bug that the test coverage I added unearthed: #3541361: Find optional field instance matches for `type: object` props (images + videos), including for optional fields on bundleless entity types (e.g. `User`'s `user_picture`).
4. while updating the OpenAPI spec, I noticed that for all 4xx responses, the generated docs say
   

   {
     "errors": [
       {}
     ]
   }
   

   is an example value. Which makes no sense, because it should be something like

   {
     "errors": [
       "The 'bla bla' permission is required."
     ]
   }

   But … this is using the ClientErrorResponse already in HEAD, which clearly is wrong for many (not all, but many) routes 😅 It's somewhat right for validation errors for data sent in various API request bodies, but it's wrong for (most?) other cases.

   Created #3541366: OpenAPI spec's `ClientErrorResponse` and `AuthenticationErrorResponse` are incorrect for most API routes for this.

The very last obstacle is supremely silly:

FILE: tests/src/Functional/ApiUiContentTemplateControllersTest.php
------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
------------------------------------------------------------------------------------------
 20 | ERROR | [x] Doc comment star missing (Drupal.Commenting.DocCommentStar.StarMissing)

… but that all is there and it DOES comply! 🙃

Just removing the comment, don't want this to be held up by that — created supported request upstream: #3541384: False `Drupal.Commenting.DocCommentStar.StarMissing` report?.