Fix: apply missing checks on block and field handling

[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

• It fixes #N/A
• The YAML export now only includes blocks the user can see in their active entities and profile.
• Blocks and fields can only be purged through a submitted form, not through a plain link.
• Values sent for read-only fields in a block tab are ignored and the stored values are kept.
• "GLPI item" fields now reject references to items that do not exist, whose type is not allowed for the field, or that the user cannot view; unchanged references are still accepted.
• Block creation rejects invalid element types, and generated class files are always resolved inside the plugin directory.
• Values sent to the dynamic block refresh script are now properly encoded.
• The form editor field selector now requires the right to edit forms and access to the block's entity.
• The obsolete FusionInventory integration is removed.

Screenshots (if appropriate):

[Rom1-B]

Should itemtypes also be validated/re-encoded in prepareInputForUpdate()? It's a real DB column update() will persist, even though the edit UI doesn't expose it.

[stonebuzz]

The GenericObject migration (inc/container.class.php:208–220) renames the tables itself, then calls update() with itemtypes provided as a JSON string. This is the same case as name, which is intentionally left unchanged for the same reason (see the comment: “see migration callers”).

Consequence

Removing itemtypes in prepareInputForUpdate() would break this migration.

My proposal

1. Extract the regex validation logic from prepareInputForAdd() into a small private method that can be reused.

2. In prepareInputForUpdate(), if itemtypes is present, decode it using PluginFieldsToolbox::decodeJSONItemtypes(). Reject the update (return false with an error message) if any entry is invalid; otherwise, re-encode it as JSON. This ensures that the migration continues to work.

3. In front/container.form.php, remove itemtypes (as well as type and subtype) from $_POST before calling update(). Structural changes should remain restricted to migrations, which is consistent with the behavior exposed by the UI.