fix(engine): handle cycles with start date correctly

[tmetzke]

• Repeats cycles with start date one time less than defined in R since the start date is the first repeat already.
• Uses the due date of the first timer as start date of the follow-up repeats because that is the actual start date of the cycle.

related to CAM-14772

[tmetzke]

@mboskamp, any ideas for tests/edge cases where this might actually break or that we at least should check specifically?

[mboskamp]

As far as I saw we currently don't test a process including a timer start event with an expression like R2/2036-11-15T11:00/PT10S. We should add at least one test deploying such a process model and also have a test method in the DurationHelperTest that tests this kind of timer configuration. I did not test your solution yet. I can add those test cases to this PR myself if you like. :)

[tmetzke]

As far as I saw we currently don't test a process including a timer start event with an expression like R2/2036-11-15T11:00/PT10S.

Does this test cover this: https://github.com/camunda/camunda-bpm-platform/pull/1973/files#diff-f0ea80f97306d22c5514dd10aa06932deada8a10266612ac8c3b85592d2a2990R1655 ?

... also have a test method in the DurationHelperTest that tests this kind of timer configuration. I did not test your solution yet. I can add those test cases to this PR myself if you like. :)

Please feel free to add that, yes 👍 🙂

[mboskamp]

Does this test cover this: https://github.com/camunda/camunda-bpm-platform/pull/1973/files#diff-f0ea80f97306d22c5514dd10aa06932deada8a10266612ac8c3b85592d2a2990R1655 ?

Yep, there is a typo in the last comment though. It should start 3 instances (like the assert statement suggests) because the corresponding process has a timer start event which is configured like this: R3/2036-11-15T11:00/PT10S

Please feel free to add that, yes 👍 🙂

Will do :)