TypedData DataDefinitions such as fields and properties can now be marked as internal

TypedData DataDefinitions which are used to define field properties and base fields can now be set as internal. Internal fields and properties should not be exposed to outside systems.

Properties that are computed will automatically be considered internal unless setInternal(FALSE) is explicitly called. This ensures backwards compatibility since computed properties of a field are not currently included in normalizations of the core Serialization and HAL modules.

Here is example of marking a field property as internal.

$properties['non_internal_value'] = DataDefinition::create('string')
   ->setLabel(new TranslatableMarkup('Computed string, non-internal property'))
   ->setComputed(TRUE)
   ->setInternal(FALSE);

Both computed as well as non-computed field properties can be marked as internal.

Base fields can also be marked as internal:

$fields['internal_string_field'] = BaseFieldDefinition::create('string')
   ->setLabel('Internal field')
   ->setInternal(TRUE);

The Serialization and HAL modules’ normalizers have also been updated to respect this data definition setting.

See \Drupal\Core\TypedData\DataDefinitionInterface::isInternal() and \Drupal\Core\TypedData\DataDefinition::setInternal().

Note that some of the fields and properties that are marked as internal may have security implications if they're exposed by an API module (such as GraphQL, JSON API, or RELAXed Web Services) anyway. For example, with #2626924: Include processed text in normalizations: "text" field type's "processed" computed property should be non-internal and carry cacheability metadata committed, the processed property of a text field is not safe to expose, because it doesn't have cacheability metadata, and will not be invalidated when necessary, which could cause information disclosure security vulnerabilities.