Split validation-related methods from FieldableEntityInterface into a separate ValidatableInterface

Should have been unpostponed 5 years ago, whoops

This blocks ✨ [PP-2] POST/PATCH config entities via REST for config entity types that support validation Needs work .

IMHO we should also do #2327883-108: Field [storage] config have incomplete settings until they are saved → here, because without it, we won't be able to actually validate some config entities! 😱 (Which is the goal stated in the issue summary.)

Quoting #2327883-108:

One thing I definitely hadn't thought of yet so far is how config entity objects may have different values in their runtime state vs their storage state, thanks to \Drupal\Core\Config\Entity\ConfigEntityStorage::mapToStorageRecord()! 😳 Fortunately, only 3 classes in core override it:

1. \Drupal\Core\Field\FieldConfigStorageBase::mapToStorageRecord()
2. \Drupal\field\FieldStorageConfigStorage::mapToStorageRecord()
3. \Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplayStorage::mapToStorageRecord()

… plus 6 in contrib, 5 of which are virtually identical to core's Layout Builder one.

This means that for config entity validation to work, the infrastructure that provides validation for config entities must also be able to call mapToStorageRecord() not just prior to save, but prior to validation. But that method is currently protected 😅 So we need some way to get config entities into the same state as just before saving. We may want to do that as part of 📌 Split validation-related methods from FieldableEntityInterface into a separate ValidatableInterface Needs work or in another issue.

@amateescu, do you have thoughts on how to do that? 🤓🙏

Also, ✨ Add validation constraints to config_entity.dependencies Fixed introduced \Drupal\KernelTests\Core\Config\ConfigEntityValidationTestBase::assertValidationErrors() which does:

  protected function assertValidationErrors(array $expected_messages): void {
    /** @var \Drupal\Core\TypedData\TypedDataManagerInterface $typed_data */
    $typed_data = $this->container->get('typed_data_manager');
    $definition = $typed_data->createDataDefinition('entity:' . $this->entity->getEntityTypeId());
    $violations = $typed_data->create($definition, $this->entity)->validate();

We may need to update that for #48.

Do we really still need this if #1818574: Support config entities in typed data EntityAdapter → already made this possible? This code was committed to Drupal core in 2018:

  public function testValidate() {
    $adapter = ConfigEntityAdapter::createFromEntity($this->entity);
    $violations = $adapter->validate();

Seems this is just a nice-to-have now?

Not to mention: not every config entity type will actually be validatable (we can guarantee this in core, not in contrib), so the existing ::isValidationRequired() is insufficient. We'd also need ::isValidationSupported() or something like that?

Demoting priority.