allow tedge commands to be linked to more than 1 cloud operation

[reubenmiller]

Is your feature improvement request related to a problem? Please describe.

Currently, we have a 1 to 1 mapping between a thin-edge.io command (in the MQTT API reference) and the mapped cloud operation.

For instance, if a component declares a generic te/<topic_id>/cmd/ot_write command capability, then the user can't create two cloud operations template files, to be linked to the generate command.

For example, the following custom cloud operation handlers both use the operation = "ot_write", but the tedge-mapper-c8y service will only link one of them (not both).

file: /etc/tedge/operations/c8y/c8y_SetCoil.template

# c8y_SetCoil -> generic `ot_write` command (write a coil point).
#
# Names the target coil point and the boolean value. `ot-command-forward` bridges the resulting
# `ot_write` command to the connector's `write` verb; the connector writes the bool to the coil.
[exec]
  topic = "c8y/devicecontrol/notifications"
  on_fragment = "c8y_SetCoil"

[exec.workflow]
operation = "ot_write"
input.point = "${.payload.c8y_SetCoil.point}"
input.value = "${.payload.c8y_SetCoil.value}"

file: /etc/tedge/operations/c8y/c8y_SetRegister.template

# c8y_SetRegister -> generic `ot_write` command (write a holding register point).
#
# The Cumulocity operation names the target point (the connector config point id) and the value
# to write. The c8y-mapper turns the cloud operation into a thin-edge command of type `ot_write`,
# which `ot-command-forward` bridges to the connector's `write` verb. The connector encodes the
# value per the point's datatype/endianness/word_order — no register coordinates on the wire.
[exec]
  topic = "c8y/devicecontrol/notifications"
  on_fragment = "c8y_SetRegister"

[exec.workflow]
operation = "ot_write"
input.point = "${.payload.c8y_SetRegister.point}"
input.value = "${.payload.c8y_SetRegister.value}"

Describe the solution you'd like

Allow users to define multiple cloud operations that are routed to the same local operation/command (like in the example above).

If the user has the two above .template files under the operations/c8y mapper, then both supported operations should be linked (i.e. the symlinks should be created) when a component publishes the local capability message:

tedge mqtt pub -r te/device/main///cmd/ot_write '{}'

Below shows the expected symlinks creation showing that both the c8y_SetCoil and c8y_SetRegister reacting on the publishing of the ot_write support.

# ls -l /etc/tedge/operations/c8y
total 20
lrwxrwxrwx 1 tedge tedge   46 Jun  3 06:40 c8y_SetCoil -> /etc/tedge/operations/c8y/c8y_SetCoil.template
-rw-r--r-- 1 tedge tedge  199 Mar 10  2025 c8y_SetCoil.template
lrwxrwxrwx 1 tedge tedge   46 Jun  3 06:40 c8y_SetRegister -> /etc/tedge/operations/c8y/c8y_SetRegister.template
-rw-r--r-- 1 tedge tedge  199 Mar 10  2025 c8y_SetRegister.template

Describe alternatives you've considered

Yes, the user could just define two different local command definitions, but this seems unnecessary.

Additional context