Add element templates support for Connectors story

What should we do?

Implement pragmatic element templates support for Zeebe matching the first Connectors User Story.

Cf. Rest connector example

• support zeebe:taskDefinition:type binding (minimum Hidden)
• support zeebe:taskHeader binding (minimum String & Dropdown)
• support zeebe:input binding (minimum String)
• support zeebe:output binding (minimum String)

What is out of scope for now, but will be interesting in the next iterations

• https://github.com/bpmn-io/bpmn-js-properties-panel/issues/559
• https://github.com/camunda/camunda-modeler/issues/2673

WIP branches

• https://github.com/bpmn-io/bpmn-js-properties-panel/commits/540-spike-c8-templates
• https://github.com/camunda-cloud/zeebe-bpmn-moddle/tree/540-templates-support
• https://github.com/camunda/camunda-bpmn-js/tree/540-c8-templates-support

Why should we do it?

To support the Connectors Project

Goals:

• Implement pragmatic support for element template descriptor to be provided by the Connectors team (DRI @nikku )
• Have this support ready ASAP as “end-2-end durchstich”

Non-Goals:

• Update of schema
• Update of schema-validation
• Logic to distinguish Platform or Zeebe templates and filter accordingly
• Refactoring of element templates architecture (given that we re-use element-templates for zeebe, this may be needed in the future)

Context

Child of https://github.com/camunda/camunda-modeler/issues/2640

[pinussilvestrus]

As shared yesterday I created a first spike on it, only supporting basic BPMN properties for now.

This gives already some clarity on which parts can easily be reused, which things have to be added (zeebe moddle descriptors, custom properties), and which things need to be refactored later (making template properties groups reusable to prevent duplications).

Looking forward to the descriptors to be added 👍

[pinussilvestrus]

After chatting with @MaxTru we decided that we will de-scope the optional property for inputs & outputs since it is not a hard requirement for the first iteration. We’d rather bring the bindings support out of the door (cf. #555), and build further features in a constructive manner.

I created a separate issue to track this: https://github.com/bpmn-io/bpmn-js-properties-panel/issues/559