Allow operation handlers to declare a different name independent of the on_fragment trigger

[reubenmiller]

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

For an upcoming Cumulocity Device Management Feature (Parameter Update), the operation handler is triggered by a different fragment (property name)
to the fragment that should be added to the device's Supported Operations list (c8y_SupportedOperations).

For example, the device parameters feature can be used to update multiple groups of parameters, where each group will have a unique fragment related to it.

Say there are two sets of properties that the device should be managing via the new Parameter Set feature, CustomProperties1, CustomProperties2. The user will create two different operation handlers which will be triggered on the uniquely identifying fragments, c8y_ParameterUpdate_CustomProperties1 and c8y_ParameterUpdate_CustomProperties2. Below shows the operation handler templates that the user will create.

/etc/tedge/operations
|-- c8y
|   |-- c8y_DeviceProfile
|   |-- c8y_DownloadConfigFile
|   |-- c8y_LogfileRequest
|   |-- c8y_RemoteAccessConnect
|   |-- c8y_Restart
|   |-- c8y_ParameterUpdate_CustomProperties1.template          <= CustomProperties1 parameter update handler
|   |-- c8y_ParameterUpdate_CustomProperties2.template          <= CustomProperties2 parameter update handler
|   |-- c8y_SoftwareUpdate
|   `-- c8y_UploadConfigFile

The above custom operation handlers will result in the Cumulocity Supported Operations fragment including both c8y_ParameterUpdate_CustomProperties1 and c8y_ParameterUpdate_CustomProperties2, where-as the Device Management UI requires just the c8y_ParameterUpdate value to be included. Below shows the different between the current and the expected values.

Current c8y_SupportedOperations values

{
    // ...
    "c8y_SupportedOperations": [
        "c8y_Command",
        "c8y_DeviceProfile",
        "c8y_DownloadConfigFile",
        "c8y_Firmware",
        "c8y_LogfileRequest",
        "c8y_ParameterUpdate_CustomProperties1",    // These two should 
        "c8y_ParameterUpdate_CustomProperties2",    // These
        "c8y_RemoteAccessConnect",
        "c8y_Restart",
        "c8y_SoftwareUpdate",
        "c8y_UploadConfigFile"
    ]
}

Expected c8y_SupportedOperations values

{
    // ...
    "c8y_SupportedOperations": [
        "c8y_Command",
        "c8y_DeviceProfile",
        "c8y_DownloadConfigFile",
        "c8y_Firmware",
        "c8y_LogfileRequest",
        "c8y_ParameterUpdate",      // Only 'c8y_ParameterUpdate' should be added, not c8y_ParameterUpdate_CustomProperties1 and c8y_ParameterUpdate_CustomProperties2
        "c8y_RemoteAccessConnect",
        "c8y_Restart",
        "c8y_SoftwareUpdate",
        "c8y_UploadConfigFile"
    ]
}

Describe the solution you'd like

Allow a custom operation handler to define the name of the Supported Operations entry that should be added to the c8y_SupportedOperations fragment, e.g. exec.supported_operation. The default can still remain to use the on_fragment value, but that is only used if the supported_operation is not set.

Handler 1: file: /etc/tedge/operations/c8y/c8y_ParameterUpdate_CustomProperties1.template

[exec]
topic = "c8y/devicecontrol/notifications"
on_fragment = "c8y_ParameterUpdate_CustomProperties1"
supported_operation = "c8y_ParameterUpdate"

[exec.workflow]
operation = "parameter_update_modbus"
input.type = "CustomProperties1"
input.operation = "${.payload}"

Handler 2: file: /etc/tedge/operations/c8y/c8y_ParameterUpdate_CustomProperties2.template

[exec]
topic = "c8y/devicecontrol/notifications"
on_fragment = "c8y_ParameterUpdate_CustomProperties2"
supported_operation = "c8y_ParameterUpdate"

[exec.workflow]
operation = "parameter_update_modbus"
input.type = "CustomProperties2"
input.operation = "${.payload}"

The name of the supported_operation can be changed to something else, e.g. declare (more generic wording to be potentially applicable for other clouds?).

Note A user could obviously just create a single handler called "c8y_ParamterSet.template", however this would assume that all of the different operation handlers are controlled by the same component (which might not be the case). For example one parameter set might want to invoke some modbus commands, where as another handler might do some custom REST API calls...each of these handlers would be potentially done by different teams/companies (due to requiring different skillsets).

Describe alternatives you've considered

An alternative could be to use a dedicated c8y.supported_operation fragment, however it might be more useful to allow other clouds to make use of this feature when publishing the list of operations that the device supports to the cloud.

Handler 1: file: /etc/tedge/operations/c8y/c8y_ParameterUpdate_CustomProperties1.template

[c8y]
supported_operation = "c8y_ParameterUpdate"

[exec]
topic = "c8y/devicecontrol/notifications"
on_fragment = "c8y_ParameterUpdate_CustomProperties1"

[exec.workflow]
operation = "parameter_update_modbus"
input.type = "CustomProperties1"
input.operation = "${.payload}"

Additional context