Add access check for using Experience Builder at all: if >=1 content entity type with an XB field can be created or edited.

🤔 Shouldn't this be the other way around, i.e. this before #3529836? Because of:

Should this permission apply to every XB route?

Devil's advocate: why this permission? Only for #3529836? It's not one of the permissions @lauriii prescribed?

I think we have an alternative solution for #4 over at #3529836-7: Enable starting with an empty XB UI (so without first having to create an entity with a component tree) 😊

I'm pretty sure @lauriii specifically wanted to AVOID this kind of permission.

So then this is the generalization of #3529836-7: Enable starting with an empty XB UI (so without first having to create an entity with a component tree), for much later!

@penyaskito's work at #3529895: Provide the client with `create` operation access information similar to #3516657 inspired me and made me realize a connection: the \Drupal\Core\Entity\EntityFieldManagerInterface::getFieldMapByFieldType()-based logic he wrote for \Drupal\experience_builder\Controller\ExperienceBuilderController::getContentEntityCreateOperations() is what #3529836: Enable starting with an empty XB UI (so without first having to create an entity with a component tree) needs as the long-term solution, rather than the pragmatic interim linked in #7.

Combine the pattern of #3529895 with the logic in ComponentTreeEditAccessCheck (from #3516432: Update all XB routes to respect content entity update/field edit access of edited XB field), and I think we have a solution!

Response for /xb/api/v0/config/component when accessing as not just the anonymous user, but also an authenticated user that for example can only edit Media entities, but not Pages nor article nodes:

{
  "errors": [
    "Requires >=1 content entity type with an XB field that can be created or edited."
  ]
}

Hah! 😄 Great minds … 🥸

Note that while reviewing #3522488: Follow-up for #3518292: `ApiContentControllers::list()`: search should exclude entity query matches for entities with auto-save data, I noticed this MR should also update

experience_builder.api.content.list:
  path: '/xb/api/v0/content/{entity_type}'
  defaults:
    _controller: 'Drupal\experience_builder\Controller\ApiContentControllers::list'
  requirements:
    _permission: 'edit xb_page'
  methods: [GET]
  options:
    _format: 'json'

Because

    _permission: 'edit xb_page'

makes no sense — it was a useful interim step, but what this issue is doing is more appropriate :)

Discussed with @effulgentsia and @penyaskito — @effulgentsia agrees this should be beta-blocking.

Maybe I'm missing something, but these changes don't quite make sense to me? 😅

Needs reroll after #3492722: Update XB to require Drupal 11.2 🙏

working on the reroll

Reroll done.

@penyaskito is working to address https://git.drupalcode.org/project/experience_builder/-/merge_requests/1... 👍

Looks good to me, found one minor nit and self-addressed it.

Just triaged #3533461 and found it to be blocked on this: #3533461-5: Only users with "edit" operation access to code components can see previews with auto-saved code components.

Found only one problem: half a dozen remaining occurrences of the access administration pages permission. Refactored them all away. Was trivial thanks to the infrastructure (and examples!) in this MR 😊👍

Echo'ing @larowlan's RTBC — this is so long overdue, and feels great to finally get XB to this point! 😊 Thanks, @penyaskito!

Got navigation.cy.js to green — it had previously implicitly (and inappropriately) been relying on the access administration pages permission, simply to use /admin/config as the "last visited URL" for the "Exit XB" functionality.

Merging at last… 🚢🥳