Add command to fix incorrectly deleted fields from containers tables

[AdrienClairembault]

Internal ref: !24075.

EDITED after #526 (see comments)

An issue affected field removal in 1.15.0, 1.15.1 and 1.15.2.
Using these versions, removing a field from a container would drop the field from glpi_plugin_fields_fields but not from the custom container table.

This command remove these incorrectly deleted fields.

Command examples:

Unrelated changes kept from the previous iteration:

• Add PluginFieldsContainerTemplate base class for custom containers classes in order to reduce the generated php classes for each containers.

The main advantage is that you can edit the generic code directly from PluginFieldsContainerTemplate and it will impact all custom container classes without having to "regenerate" the PHP files of these custom classes.

[cedric-anne]

Even if such a solution would work, I think it would be better to delete data from DB when field/dropdown is deleted, for instance in PluginFieldsField::pre_deleteItem() and in PluginFieldsDropdown::destroy().
For existing data, cleaning could be handled in migration.

[AdrienClairembault]

Looking at PluginFieldsField::pre_deleteItem(), not deleting the fields seems to be done on purpose (the code to delete is there but only run on very specific conditions).

[cedric-anne]

It seems it was only done to improve performances (see 5d087e1). IMHO, not deleting data from DB when deleting a field is a problem and should be fixed.

[cedric-anne]

Values were cleaned in old plugin db schema, and this clean has not been adapted to new schema, see 455c2c2.

[cedric-anne]

Maybe the deletion chain should be reviewed.

• Container child should be deleted in cleanDBonPurge() method of container.
• Container/Dropdown files should be deleted in post_deleteFromDB() method of corresponding item.

[AdrienClairembault]

Actually, after re-reading the code I've found that deletion was just broken since 1.15.0.

removeField was called with the wrong parameters since 954864b#diff-8fd65f1eb4cf4f2c2b956a535e6de83c36b63bfabfd1a3c9131b99a39e47b9a7L219 (it's supposed to be name first, type second).

[AdrienClairembault]

I'm not sure about a migration to remove the missing fields... any mistake which would delete legitimate fields would have a huge impact.

[cedric-anne]

case preg_match('/^dropdown-.+/i', $field_type): was a legitimate case and should be preserved.

Diff is huge here, and it is hard to validate the code. Unless I am wrong, if #528 is merged, only the new command and corresponding PluginFieldsMigration methods are required.

I would prefer serarate PR for PSR-12 migration and for migration of PHP template files to abstract classes (should be done globally). We could work on these later.

[AdrienClairembault]

Ok, let's merge #528 and then I'll open separate PR for each topics.

PS: for the huge diff, it's mostly whitespaces and you can ignore them:

[AdrienClairembault]

Replaced by #532.