We've removed some previously deprecated FieldTypes from our configuration and initial data, but we also need to provide the Developers a way to "upgrade" their existing installation by removing Field Type of the given identifier from database (multiple core tables are involved).

Otherwise it leads to errors like this:

In ConverterRegistry.php line 65:
  Could not find 'eZ\Publish\SPI\Persistence\Content\FieldValue\Converter\*' with identifier 'ezsrrating'

This is in general useful cleanup feature and useful enough to provide it in 2.5.x.

TBD: how we can drop external storage data in a generic way (for 3rd party Field Types).

Spec:
TBD: if the errors occur while loading container or during runtime (in the former case spec will need adjustments):

To be implemented as the ezplatform:upgrade:delete-field-type Command provided in EzPlatformCoreBundle.

Usage: php ./bin/console ezplatform:upgrade:delete-field-type <field-type-identifier> [options]

The command options:

• --delete-from-content-types (default: no/false), but provide a warning that CT won't be affected unless this is set
• --content-id=<int:content-id>[], provided as an array argument, cannot be combined with -delete-from-content-types (throw an exception),
• --subtree=/1/2/ cannot be combined with -delete-from-content-types (throw an exception),
• --dry-run reporting number of elements to delete,
• --non-interactive.

Not considering:

• Privileged user argument, let's use sudo (based on my experience).
• Iteration count argument. Deletes should be fairly light. Rather won't do any loading anyway due to possible exceptions (see above).

It would be useful if the command reported left-overs, like existence of an External Storage, existence in Content Types, existence in the container (services providing FTs).

This feature can be split into smaller iteration-based sub-tasks.