Entity forms skip validation of fields that are not in the EntityFormDisplay

Spin-off from #2002180: Entity forms skip validation of fields that are edited without widgets →

Postponed on
#2429037: Allow adding entity level constraints →
and
#2105797: Add CompositeConstraintBase so that constraints involving multiple fields, such as CommentNameConstraint, can be discovered → which is postponed on
#2343035: Upgrade validator integration for Symfony versions 2.5+ → .

Problem/Motivation

• Entity changed validation (=ensure no one edited the entity while editing it) gets ignored by all entity forms but nodes right now. It works for nodes only, because NodeForm takes care of it manually while all the other entity forms aren't.
• Suppose you have 2 fields (A and B) in a given entity type + bundle.
• Suppose field B has a validation constraint that depends on the contents of field A (e.g., field A is "date of foo", field B is "date of bar", and you want a validation constraint on field B that it is later than A).
• Create 2 form displays: one that contains both A and B, and one that contains only A.
• Using the first form, you can create an entity with values for A and B that satisfy all constraints.
• If you now edit with the 2nd form, you can change A to something that makes B's value violate its constraint, but because the form only contains field A, that's the only field that will get validated, so the form will submit and the entity will get saved successfully, despite being invalid according to its full constraints.
• Currently, we run validation against fields on the entity forms that have widgets. However, if a field can be edited with a form element that is not a Field API widget, we do not validate its value at the field-level (i.e., check it against the field's constraints). The form element might have its own custom #element_validate, but since that's a custom function, there's no guarantee that it results in a value that satisfies the field's constraints.

Proposed resolution(s)

• On form submit, validate the entire entity rather than only the fields in the form.
  • Allow adding entity level constraints for general validation logic that should run for all changes (e.g. entity changed validation): #2429037: Allow adding entity level constraints →
  • Ensure all constraints are bound to fields (#4.1) only and document that restriction. (requires above task)
  • Work over form validation logic to run complete entity validation, ignore violations based on field access by default (make it overridable from the entity form?)
  • #2105797: Add CompositeConstraintBase so that constraints involving multiple fields, such as CommentNameConstraint, can be discovered →
• However, what to do about violations that are reported for fields that aren't on the form? For example, if B reports the violation (since it's the one with the constraint), its violation message might not make sense (and might expose confidential information, such as that such a field exists) to a person who only sees what's on the form.

Remaining tasks

API changes

• EntityFormDisplayInterface::flagViolations() has been added
• FieldableEntityInterface::validate() now returns EntityConstraintViolationListInterface instead of ViolationListInterface (no API change for callers)
• Content Entity Forms now have to override ContentEntityForm::getEditedFieldNames() & ContentEntityForm::flagViolations() for flagging violations for customly added base fields

User interface changes

There is the potential for a UI change. If we validate the entire entity and a field that isn't on the form has a violation, we need to inform the user that they need to contact an administrator or something. In other words, we need to tell them that they won't be able to submit the form until all the constraints are passing, including on the fields they don't have access to modify.

We use the following message for that:

+            $message_template = 'The validation failed because the value conflicts with the value in %field_name, which you cannot access.';

Beta phase evaluation