Remove the concept of "enabledness" from the JSON API module, rely on the Entity Access API instead

Done.

Doing so made me touch code where I was wondering whether the Entity Access API was already being used for relationships/includes. AFAICT it is not. This implies that already the JSON API module is violating the Entity Access API. It's currently only checking it for accessing individual entities, and it's checking field access when modifying a relationship. But it's not checking entity access when following relationships.

It's \Drupal\jsonapi\Normalizer\EntityNormalizer::serializeField() that generates an EntityCollection object, which is what will be used later to comply with ?include=… instructions. It does this:

    $access = $field->access('view', $context['account'], TRUE);
    if ($field instanceof AccessibleInterface && !$access->isAllowed()) {
      return (new NullFieldNormalizerValue())->addCacheableDependency($access);
    }

This is indeed fine to determine whether a field is viewable. But in the case of an entity reference field, you need both reference field access and access to the referenced entity to be allowed. See e.g. \Drupal\Core\Field\Plugin\Field\FieldFormatter\EntityReferenceLabelFormatter, it calls \Drupal\Core\Field\Plugin\Field\FieldFormatter\EntityReferenceFormatterBase::getEntitiesToView(), which does the entity access checking.

So, opened an issue for that: #2838646: Relationships violate Entity Access API.

Gah, this conflicts with #2831185: Rename DocumentWrapper to JsonApiDocumentTopLevel and DocumentRootNormalizer to JsonApiDocumentTopLevelNormalizer. Would be great if that one would be committed.

And e0ipso just committed that! Unblocked, re-testing.

#7:

1. It's already enabled by default. i.e. it's opt-out, not opt-in.
2. If you get it wrong in your entity access handler, then the same vulnerability is likely exposed elsewhere on the site.
3. If you get it wrong in your entity access handler, you're completely missing test coverage for something critical to security. We shouldn't babysit broken code.
4. The only alternative to what you suggest is to require developers to manually enable/expose every single entity type/bundle: opt-in instead of opt-out. Which is what the core REST module does. Which is a very frustrating process.

The whole point of the JSON API module is that it makes it easy to follow relationships. Requiring every entity type to be manually enabled completely nullifies that. If we'd do that, then I don't think there'd be much of a point to the JSON API module.

#2831134: Remove configurable 'id_field': always use UUID conflicted with this, rerolling…