feat(18944): Add codeless interpolation for the Data Hub messages

[vanch3d]

See https://hivemq.kanbanize.com/ctrl_board/57/cards/18944/details/

The PR introduces a reusable message (text) editor with support for variable interpolation.

The driving principle of the editor is to avoid the manual editing of the internal representation of a variable, i.e. ${policyId}. This is fraught with error due to misspellings (e.g.${policyid}or $(policyId) or$policyId}`), which will limit parsing and feedback in the text field.

The editor introduces the variables as a single token, created by auto-complete from the trigger character (@, see below) and selection from a filtered list of acceptable terms.

The variables are rendered differently from the rest of the text, cannot be edited by can be deleted as a single character (backspace for eemple).

The variables are converted to their proper internal syntax (e.g. @policyId to ${policyId}) on publishing. The internal syntax is also parsed and transformed to the token at loading (see below for caveats).

Design

• The interpolation editor is implemented through the open-source headless content editor Tiptap (https://github.com/ueberdosis/tiptap)
• The interpolation variables are handled through the mention plugin of the editor (https://tiptap.dev/docs/editor/api/nodes/mention), which delivers the required features (customised token, copy-and-paste, auto-complete)
• The trigger for the autocomplete is based on a single character. The opening ${ would not work. so we are using the $
• The underlying technology for the editor is an HTML WYSIWYG component, used to render the interpolation token. But the output is plain text:
  • token are converted to their internal syntax ${policy}
  • text is escaped from the content of the editor; any HTML code will be cleared out
• Copy and paste is supported
• typing any internal variables in plain text, e.g. ${policyId} will also work. It will not be replaced by a token until the form is loaded again.
• However, there is no validation (yet) of manually edited variables: a ${illegal} variable will be converted to the @illegal token, even if not in the list of acceptable terms

Out-of-scope

• The editor is deployed only for the message in System.log operations. It will be generalised to the other relevant fields across Data Hub once the "conflict" or customisation are sorted out.
• the list of variables is currently statically defined in the front end. It will be delivered by a dedicated API endpoint in a subsequent ticket
• the context of the availability of the variables (data or behaviour policy) will be implemented in a follow-up ticket

Before

After

[sfrehse]

The placeholder name for the text field contains metricName which isn't correct for System.log.

[sfrehse]

• The margins of the next to the border look a bit wrong.
• Initially, I though the red variables have an error -> what about making it just gray?
• I don't see the problem with a $ trigger.
• ToState and FromState are only available in behavior policies -> should be returned by the REST API or OpenAPI Spec?

[vanch3d]