Allow cardinality to be restricted (overriden and reduced) in the field instance settings

Just as an update, field config cardinality is going strong and will be addressing the constraint update soon, so if your looking into this feature, give it a spin.

It seems the use cases described in the OP could also be addressed by #1234624: Limit the number of fields to display → .

I've been thinking about this issue in the past couple of days, and I think there is a way to implement this cleanly thanks to the OO code that we didn't have in D7.

Here's my plan for how we could do this in D10+:

• deprecate FieldStorageDefinitionInterface::isMultiple() and FieldStorageDefinitionInterface::getCardinality()
• introduce FieldStorageDefinitionInterface::isStorageMultiple() and FieldStorageDefinitionInterface::getStorageCardinality() to replace them
• introduce FieldDefinitionInterface::isMultiple() and FieldDefinitionInterface::getCardinality() that would default to the new storage methods
• the new methods above also solve the problem of BaseFieldDefinition, which implements both FieldStorageDefinitionInterface and FieldDefinitionInterface, so the storage-level cardinality would still have to be specified, but each bundle-level field definition could use a different cardinality (equal to or lower than the storage-level one)
• write a detailed change record to explain the difference between the storage-level and field-level cardinality, and when each of them should be used (hint: the field-level cardinality is the one that should be used in most cases)

This approach achieves the following goals:

• before the existing methods are removed from core, contrib and custom module authors will get a heads-up that they have to change something
• after the methods are removed from core (e.g. in 11.0), they will need to take this change into consideration and update their code accordingly

@Wim Leers, re #99, note that core already defines a Count constraint based on the field storage cardinality in \Drupal\Core\Field\FieldItemList::getConstraints(), and it would just need to be updated to use the field-level cardinality instead.

Before touching anything about cardinality, I think we should address the overlap between actual cardinality and the required flag.

Let me explain…

In non-technical language cardinality is represented as 0..N or 1..10, etc. An equivalent representation would be

I think we should aim for this representation which would make “required” obsolete and will allow to set the lower limit.

We can even imagine a lightweight value class to store cardinality while fetching from backend.

readonly class Cardinality {
  public function __construct(
    public int $min,
    public ?int $max = NULL,
  ) {
    …validation goes here
  }
}