fireedge: fix serialization for list-multiple user inputs

[a9sk]

Description

This PR fixes a serialization bug in the FireEdge UI where listMultiple user inputs were being sent to the server as native arrays or duplicate parameter keys.
Because the backend XML-RPC/core parser expects a single string for these fields, standard HTTP parameter parsing was overwriting all but the final selected value.

The bug

For a more technical breakdown of the bug, here is how the data flow was breaking down:

1. An user defines a VM template USER_INPUT using the list-multiple type;
2. When more options are selected, FireEdge safely tracks this selection internally as a standard JavaScript array (e.g., values: ["val1","val2","val3"] (to keep ordered));
3. Upon submission, the form wrapper attemps to pass the native array into the HTTP request body without prior string serialization. This means that, depending on the exact wrapper, this gets serialized over HTTP as repeated duplicate keys (e.g., <values>val1</values>,<values>val2</values>,<values>val3</values>);
4. When the backend parser maps incoming HTTP parameters int a dictionary, it loops throught these duplicate keys sequentially. Because keys must be unique, each subsequent value completly overwrites the previous one. Ultimately, the VM only ever recives the very last selected item (e.g., values="val3").

Solution

This patch resolves the issue by intercepting the form state right before submission via the .afterSubmit hook in both UserInputs.js and utils/schema.js. It transforms the array into a comma-separated string (e.g., values="val1,val2,val3"), which aligns with how the backend stores and parses these attributes. It also includes an empty-array check to return undefined, preventing the submission of unintended empty strings for optional fields and stripping the key cleanly from the payload instead.

A note on standardization and CLI implementation:
This fix patches the UI to match the backend's current string-based parsing. However, if comma-separated strings are not intended to be the long-term, standardized data structure for list-multiple attributes, it might make sense to standardize this data type natively across the core API.
If this comma-separated solution is intended, please keep this behavior in mind when documenting and eventually implementing list-multiple support for the CLI natively (issue: #7055).

Branches to which this PR applies

• master
• one-X.X

---

• Check this if this PR should not be squashed