`api.config.get` route returns data without any authentication due to broad `view` access

I just realized that I meant to open the issue for api.config.get, that's where I originally discovered the problem.

That shouldn't be the case:

experience_builder.api.config.get:
  path: '/xb/api/v0/config/{xb_config_entity_type_id}/{xb_config_entity}'
  defaults:
    _controller: 'Drupal\experience_builder\Controller\ApiConfigControllers::get'
  requirements:
    _xb_http_eligible_config_entity: 'TRUE'
    _entity_access: 'xb_config_entity.view'
    # Allow a subset: `Component` config entities are read-only via the internal HTTP API.
    xb_config_entity_type_id: '(pattern|js_component|xb_asset_library)'

AFAICT this is simply questioning #3508694: Permissions for XB config entity types's introduction of explicit access for all?

IOW: authentication & authorization are present, authorization is simply granted very broadly.

I suspect what we want is the _user_is_logged_in thing #3508694: Permissions for XB config entity types did for experience_builder.api.config.list:

experience_builder.api.config.list:
  path: '/xb/api/v0/config/{xb_config_entity_type_id}'
  defaults:
    _controller: 'Drupal\experience_builder\Controller\ApiConfigControllers::list'
  requirements:
    # Any internal HTTP API-eligible XB config entity type.
    _xb_http_eligible_config_entity: 'TRUE'
    # But deter users from trying to access other config entities via this route: this ensures 404 responses rather than
    # 403.
    # @see \Drupal\Tests\experience_builder\Functional\XbConfigEntityHttpApiTest::testNonXbConfigEntity()
    xb_config_entity_type_id: '(component|pattern|js_component|xb_asset_library)'
    # The UI client can fetch all the components the current user has access too, regardless of which kind of XB-enabled
    # entity you're editing.
    _user_is_logged_in: 'TRUE'
  options:
    # Indicate that external applications may use this route. For authentication, see `modules/xb_oauth/README.md`.
    xb_external_api: true
  methods: [GET]

Because here's the thing: @lauriii wanted XB to both:

• only have a single simple "admin permission" per config entity type: JavaScriptComponent::ADMIN_PERMISSION etc.
• NOT have a catch-all "use XB" permission — see #3452581: [META] XB Permissions's functional requirements

See:

1. my write-up about about this at #3508694-14: Permissions for XB config entity types.2
2. my very detailed write-up about the consequences of this at #3508694-19: Permissions for XB config entity types.2
3. confirmed by @lauriii at #3508694-20: Permissions for XB config entity types

Either we must do what I just pushed based on #4, or, and probably that's the safer option, \Drupal\experience_builder\EntityHandlers\VisibleWhenDisabledXbConfigEntityAccessControlHandler should be narrows to only logged in users rather than the current

      // We always allow viewing these entities, even if disabled.
      'view' => AccessResult::allowed(),

Actually, I think we can do both, but perhaps that means the first commit is now obsolete. Did that, now VisibleWhenDisabledXbConfigEntityAccessControlHandlerTest is (understandably!) failing.

Updated cacheability expectations of integration tests; those are passing now. But, this MR still needs to expand assertAuthenticationAndAuthorization() to facilitate testing GETting an unauthorized individual config entity (i.e. the new test coverage that this issue needs).

Leaving that for somebody else to finish 😇

#3530590: Expand functional test coverage for ContentCreatorVisibleXbConfigEntityAccessControlHandler is in, which means we kinda don't need this test coverage here anymore … except that it would be good to generalize to all XB config entity types, instead of just Pattern.

Added tests for anonymous GET at assertAuthenticationAndAuthorization based on openapi examples, so we can generalize to all XB config entity types.

VERY nice work here, @penyaskito!