feat: support zeebe:calledElement templating

[barmac]

This PR implements zeebe:calledElement binding. In the implementation, the template developer is required to provide inputs and outputs explicitly as variable propagation is disabled for the templated elements.

Related to camunda/camunda-modeler#3006

[nikku]

Looks great!

One concern I have is whether we actually need to set propagateAllChildVariables (and the other one) or not.

I believe (to be double-checked) the engine ships with sensible defaults there. We could rely on them and simplify our solution.

[barmac]

According to the docs, per default the engine propagates all of the variables from the child process to the call activity. So if we don't set the property to false and the element does not have outputs, the engine copies all of the called process variables to the parent scope. In the implementation, I want to enforce explicit mapping to avoid unexpected leak of variables to the parent scope.

Perhaps a better solution would be to propagate variables only when requested by the user, but that would have to be fixed within the engine. WDYT?

[nikku]

WDYT?

I completely agree with your rationale. We want to be safety first and prevent accidental leaks. Thanks for confirming.

Note that there is a catch though:

This behavior can be customized by defining output mappings at the call activity. The output mappings are applied on completing the call activity and only those variables that are defined in the output mappings are propagated.

So if we operate under the assumption that any sane re-usable building block / template uses output mappings, then we're fine without explicitly setting the property.

[barmac]

So if we operate under the assumption that any sane re-usable building block / template uses output mappings, then we're fine without explicitly setting the property.

I'm not sure if we can assume this. I can also imagine that a call activity does not emit outputs, and I don't want to write its internal variables to the parent scope:

[nikku]

You got me with "not emitting variables". This is a case, especially considering our "re-usable building block" theme we want to prevent surprises at all costs.

---

I shared this thought with the Zeebe folks, too.

[barmac]

I updated the PR with the already released schema/validator. @nikku I think we can merge and release it. WDYT?

[nikku]

Looks great. Let's get this released.