Add retry configuration properties to OOTB connector templates

[chillleader]

What should we do?

In 0.22.0 we have introduced the support for retry backoff. Now we should support these new features in all outbound OOTB Connector templates:

• Retries (type zeebe:taskDefinition:retries) to define the number of retries
• Backoff (type zeebe:taskHeader, name retryBackoff) to define the backoff in ISO 8601 duration format, e.g. PT1M

We can choose either one of the following options:

• Add these properties to all OOTB templates
• Only add these properties to first-class connectors such as REST & GraphQL, and protocol connectors can be pre-configure with a meaningful value or not set this at all (which will result in 3 retries).

Why should we do it?

To make the new retry features accessible to the general audience.

[bastiankoerber]

we will combine this with our generator epic

[sbuettner]

As discussed in grooming:
Default value for retries: 3
Default value for retryBackoff: 0

Include in element template generator as a non-hidden property in a new "Retry" category which should be collapsed by default (after the Error handling category).

[chillleader]

After testing the retries templating altogether I discovered a blocker for this issue. Although zeebe:taskDefinition:retries binding exists in the element template schema, it is actually not implemented in the modeler, and there is a stale PR that is supposed to add the support. There is also an open issue to track this: camunda/camunda-modeler#2936

[saig0]

I'm looking forward to seeing this feature soon. 🚀

My use case:
I have a connector template that uses the REST connector. It calls an API with a rate limiting. If the connector is invoked too often (e.g. in a multi-instance activity), the request is blocked. It must wait a few seconds until it can retry. Currently, I would need to model the retry by myself in all places where the connector is used

I want to use the retryBackoff to handle the rate limiting. For example, by setting the retryBackoff to PT10S.

A fixed duration would be a great help. But we could provide even better options:

• exponential backoff: built-in with a given factor and a limit
• randomized with a limit (i.e. salting): for example, wait between 1 and 10 seconds