Field schema no longer uses 'not null' entries

While generating field schema, the not null schema entries defined by the field type plugin are no longer taken into account, hence they should be removed to avoid introducing confusion.

All the not null entries are automatically generated based on the required value of field properties, which determine which schema columns should actually be populated for the field value to be meaningful.

This approach allows the schema handler to decide whether adding a not null clause is sensible in a particular context. For instance when adding a base field column to a base table containing existing data, a not null clause makes no sense, unless an initial value is available.

Before:

class BooleanItem extends FieldItemBase implements OptionsProviderInterface {

  public static function propertyDefinitions(FieldStorageDefinitionInterface $field_definition) {
    $properties['value'] = DataDefinition::create('boolean')
      ->setLabel(t('Boolean value'));

    return $properties;
  }

  public static function schema(FieldStorageDefinitionInterface $field_definition) {
    return array(
      'columns' => array(
        'value' => array(
          'type' => 'int',
          'size' => 'tiny',
          'not null' => TRUE, // This is hardcoded and not semantic.
        ),
      ),
    );
  }

After:

class BooleanItem extends FieldItemBase implements OptionsProviderInterface {

  public static function propertyDefinitions(FieldStorageDefinitionInterface $field_definition) {
    $properties['value'] = DataDefinition::create('boolean')
      ->setLabel(t('Boolean value'))
      ->setRequired(TRUE); // This allows the schema handler to decide how to handle each case.

    return $properties;
  }

  public static function schema(FieldStorageDefinitionInterface $field_definition) {
    return array(
      'columns' => array(
        'value' => array(
          'type' => 'int',
          'size' => 'tiny',
        ),
      ),
    );
  }
  
}