Field sql storage has an unrestricted unserialize() call

Problem/Motivation

This was originally logged as a private issue to the security team, but was cleared to be moved to the public queue

The field sql storage (like the cache layer) has an unrestricted unserialize() call.
In https://www.drupal.org/project/drupal/issues/2232427 📌 Allow field types to control how properties are mapped to and from storage Needs work the question arose if can lead to another instance of SA-CORE-2019-003 which is about api-injected evil data (but i'm not familiar with the internal details of that one).

Some research:
- Core uses serialized storage of objects in section storage (see https://www.drupal.org/project/drupal/issues/3484469 📌 Do not store sections as PHP objects Active ).
- Custom code may use that too (i'm doing it a lot)
- The unserialize() is in \Drupal\Core\Entity\Sql\SqlContentEntityStorage::mapFromStorageRecords
- Mitigation: As i grok it, an attack can only happen if evil data passes through the (core / custom) FieldItem class and is written to DB.

More eyes needed:
- Some more eyes please cross-check the claim "an attack can only happen if evil data passes through the (core / custom) FieldItem class and is written to DB." as that is fundamental to all the following.

Steps to reproduce

Proposed resolution

- add a warning to the 'serialize' property for field item storage in FieldItemInterface::schema, sth like "If 'serialize' is used, the FieldItem class is responsible to prevent storage of evil classes, via ::setValue or custom TypedData class"
- add a allowedClasses whitelist to 'serialize' and deprecate usage without it.
- add comments to all unresticted serialize() calls and possibly add a code style rule to guard that.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Background information

• security.drupal.org private issue: https://security.drupal.org/node/181891
  (included for reference. Please do not report access denied as an error.)

List of people initially involved and should receive credit here:
bradjones1
bramdriesen
mcdruid
benjifisher
greggles
geek-merlin