Fix #911: decouple project editing from BOM size

[T0b121]

Fixes #911

Problem

Editing or moving a project submitted the complete BOM as part of the project metadata form.

For projects with hundreds or thousands of BOM entries, this created a very large POST request. Each BOM entry contributed multiple form fields, so PHP's default max_input_vars limit could be reached at roughly 142 entries. This caused incomplete requests and failures such as invalid CSRF tokens.

This PR does not increase PHP limits. Instead, it removes the unnecessary BOM data from project metadata operations.

Reproduction and observed behavior

I also tested the previously suggested workaround of increasing the relevant request/buffer limits. This allowed the form submission to complete, but it did not solve the underlying scalability problem.

• With around 200 BOM entries, opening the project metadata edit page already caused noticeable loading times.
• With around 500 BOM entries, the BOM import completed, but the application did not reliably redirect back to the project page afterwards and remained on the import page.
• With 1000 BOM entries, editing project metadata was no longer practical: loading the edit page took several minutes even on a powerful server.

The issue is therefore not only the request-size limit. Loading, rendering, validating, and submitting the complete BOM as part of a project metadata operation does not scale.

Changes

• Remove the complete BOM collection from the project edit form.
  • Renaming, moving, and editing project metadata now submit only project metadata.
• Keep BOM management available through the existing paginated BOM table.
  • Added separate edit and delete actions for individual BOM entries.
  • Changes can still include a log comment and are recorded through the existing logging mechanism.
• Keep BOM validation during BOM imports.
  • The validation groups separate metadata validation from explicit BOM validation, so project edits do not validate or initialize the complete BOM.
• Use an extra-lazy BOM relation and avoid loading every BOM entry during project metadata validation.
• Avoid expanding all BOM entries when rendering project edit history.
  • Individual BOM entry history remains available on the corresponding BOM entry.
• Add regression tests and CSV fixtures for projects with 100, 200, 500, 1000, 1400, and 1500 BOM entries.

Screenshots

Paginated BOM table with 1501 entries

The BOM is displayed server-side paginated. The screenshot also shows a BOM entry added after the large CSV import.

Last page of the BOM table

The final page confirms that the complete BOM remains accessible without being included in the project metadata form.

Separate BOM entry editing

Each BOM entry can be edited or deleted separately, including an optional change comment.

Project metadata editing

Project metadata editing no longer renders or submits all BOM entries.

Verification

Automated:

OK (12 tests, 81 assertions)

The targeted tests cover:

• importing BOM CSV files with 100 to 1500 entries;
• opening and renaming a project without rendering BOM form fields;
• editing and deleting a single BOM entry separately;
• existing BOM CSV export behavior.

Manual production-mode test:

• created a project;
• imported 1500 distinct BOM entries;
• deleted one BOM entry;
• created two additional parts and added them to the project;
• verified the paginated BOM table and separate BOM entry editing.

Review note

I mainly work with Python and JavaScript for data processing and have not worked with PHP or web UI design for more than ten years. I used AI assistance while investigating and implementing this proposal.

The targeted automated tests and the manual production-mode test passed. Before merging, I would therefore especially appreciate a maintainer review of the Symfony/Doctrine conventions, the UI integration, validation behavior, and potential side effects.