Fix(Migration): prevent container name corruption on partial update

[stonebuzz]

Checklist before requesting a review

Please delete options that are not relevant.

• I have performed a self-review of my code.
• I have added tests (when available) that prove my fix is effective or that my feature works.
• I have updated the CHANGELOG with a short functional description of the fix or new feature.
• This change requires a documentation update.

Description

During plugin installation when migrating containers from GenericObject to
CustomAsset, containers end up with a corrupted name field (e.g.
sixonefourfourthreesixtwozeroeight) and an empty label, causing a
subsequent MySQL error when the dynamic table name exceeds 64 characters.

Root cause

installBaseData calls update() with only id and itemtypes (no label key to update) see L249

prepareInputForUpdate() called prepareLabel() unconditionally, which:

1. passed '' to getSystemNameFromLabel(), which fell back to
   random_int(0, mt_getrandmax()) for an empty name
2. passed that integer through replaceIntByLetters(), spelling each
   digit out (6 1 4 4 3 6 2 0 0 8 => sixonefourfourthreesixtwozeroeight)

State before migration

mysql> SELECT id, name, label, itemtypes FROM glpi_plugin_fields_c
+----+---------+---------+--------------------------------+
| id | name | label | itemtypes |
+----+---------+---------+--------------------------------+
| 3 | contain | contain | ["PluginGenericobjectContain"] |
+----+---------+---------+--------------------------------+

State after migration (buggy)

+----+------------------------------------+-------+-------------------------------------+
| id | name | label | itemtypes
+----+------------------------------------+-------+-------------------------------------+
| 3 | sixonefourfourthreesixtwozeroeight | | ["Glpi\CustomA
+----+------------------------------------+-------+-------------------------------------+

This triggers:

RuntimeException: MySQL query error: Identifier name
'glpi_plugin_fields_glpicustomassetcontainassetsixonefourfourthree
is too long (1059)

[stonebuzz]

Currently, updating the label and/or name triggers the regeneration of the associated database tables and generated files. This behavior is not desirable and was not possible in previous versions. I'm not sure when this change was introduced, but it should be reverted.

[stonebuzz]

close in favor of

#1225