feat(22908): Add Data Point selector to the relevant adapter's config form

[vanch3d]

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

The PR is the first step in the Data Point Discovery epics, introducing a custom selector for the "tags" that are discoverable from the adapters.

The custom widgets collect the data points from the adapter and present them as the now-ubiquitous auto-select component. Searching and filtering are based on the name, id and description of the data points, allowing deeper selection.

In the current release, MODBUS and OPC-UA are the only two adapters that offer data point discovery (as defined by the DISCOVER flag of the adapter type.

The PR also closes https://hivemq.kanbanize.com/ctrl_board/57/cards/22906/details/.

Design

• The widget needs to be activated for the relevant properties of the adapter. It will require a custom discovery:tagBrowser ui:widget on the adapter's uiSchema, e.g. for modbus:

  "subscriptions": {
  "ui:batchMode": true,
  "items": {
    "addressRange": {
      "endIdx": {
        "ui:widget": "discovery:tagBrowser"
      },
      "startIdx": {
        "ui:widget": "discovery:tagBrowser"
      }
    }
  }
  }

• The widget requires the adapter to be discoverable and to have data points retrieved from the API. If the conditions are not met, the UI will revert to the "standard" widget, based on the property type

Out-of-scope

• The requirement for the widget to have a list of items flattens the tree, potentially losing the informativity of the individual data points. This will be investigated in a different ticket, https://hivemq.kanbanize.com/ctrl_board/57/cards/23319/details/
• The data point discovery API requires the adapter to be defined (as described by the mandatory adapterId of the request. It means that the widget cannot be used for new adapters, since they won't be defined yet. A refined UX and implementation will be part of a separate ticket, https://hivemq.kanbanize.com/ctrl_board/57/cards/23322/details/
• OPC-UA and MODBUS seem to utilise different properties of the data point (id and name respectively), and type casting is also required. A custom configuration for the value mapping will be implemented in another ticket, https://hivemq.kanbanize.com/ctrl_board/57/cards/23323/details/
• There is a real need to evaluate the impact of the widget on user experiences. MODBUS in particular structures data in a way that is way less efficient than just manually editing the indexes of the registers. A new UX will be investigated in a subsequent ticket

Before

After