Configure retry behavior based on status code

[berndruecker]

We should allow the retry behavior to be dependent on the status code, see e.g. https://softwareengineering.stackexchange.com/questions/341518/rest-how-to-determine-transient-exceptions

I don't think the worker should make a final decision, but it should also be configurable (e.g. 503 should be retried, but 500 not).

[saig0]

Currently, it is possible to configure when a job should be completed, failed, or throw an error event.

@berndruecker do you need more than this? Please describe your use case which is not covered.

[berndruecker]

Assume you hit a service with 503 (temporarily unavailable), then a great behavior would be to retry later.

Or should be let the job fail in this case, which will use the built in retry (which needs to be able to use a delay - but that's a different story)?

[saig0]

So, you would like to do the retry in the job worker itself instead of failing the job?

Assuming that we will implement the job retry with a timeout (camunda/camunda#164) soon, would you still prefer the try handling in the job worker? Why?