Always enforce basefield and entity-level constraints

This came up for consideration as a BugSmash Initiative issue of the day, but I suggest it's better to consider it a major task. It's an architectural design decision, not a bug, and changing it would have the potential for significant disruption.

That said, it also seems perfectly achievable to do this. We already have the FieldableEntityInterface::setValidationRequired() method, and we can begin by throwing a deprecation if an invalid entity is saved without explicit opt-in.

Let's see how many tests that breaks.

The user module creates an anonymous user when it is installed, but that user has no username and so is invalid; fixed with ->setValidationRequired(FALSE).

OK, so doing this is moderately disruptive.

1. A lot of tests would need updating because test code often creates entities programatically in a fairly sloppy way. The entities are invalid not because they need to be to serve thes test logic, but because no one has really noticed and it doesn;t matter for the test. For example, test users created without an email address. We can use ->setValidationRequired(FALSE) to fix this for existing tests, but future tests will benefit from the encouragement to create properly valid entities, as valid entities are a more typical representation of production situations.

2. Some core validators are access sensitive! ValidPath consraint is one clear example I've looked into, but the test failures here suggest others. If a validator is access sensitive it is likely to cause a validation failure unexpectedly when saving an entity outside of a form submission. I think we need to clarify that validators should not consider the current user, they need to validate the entity in its own terms independent of any context. Otherwise if the context changes, the entity becomes invalid and no longer saveable.

Do we want to proceed in this direction?

Just chiming in to say thanks for working on this

Some core validators are access sensitive! ReferenceAccessConstraint, ValidPathConstraint and ModerationStateConstraint are clear examples

I think the correct solution is to support Symfony's validation groups. This would actually be remarkably easy because we have most of the code to support it anyway in the TypedData system, and Symfony expects validation groups to be provided when defining constraints as a possible value in the options array that we already support.

What we would simply need to is:

1. Change the internals of RecursiveContextualValidator to pass the $groups parameter from RecursiveContextualValidator::validate(..., $groups) through to TypedDataMetadata::findConstraints($group).

2. Change the internal of TypedDataMetadata::findConstraints($group) to filter constraints by group.

3. Either add to EntityInterface and EntityBase a new method addValidationRequired($group), or change the parameters of EntityInterface::setValidationRequired() to receive an array instead of or in addition to a boolean.

4. Change the internals of EntityBase::validationRequired and EntityBase::validate() to store the groups that require validation in EntityBase::validationRequired and pass that along to TypedData::validate() so that it can pass it to RecursiveContextualValidator::validate().

5. In ContentEntityForm::buildEntity() invoke our new $entity->addValidationRequired('form');

To ensure that the valid path constraint which is sensitive to the current user's access permissions only runs when a form is submitted, the developer would do this:

    $fields['path'] = BaseFieldDefinition::create('string')
      ->addPropertyConstraints('value', [
        'ValidPath' => [
          'groups' => ['form']
        ]]);