Activity timeouts and retry policy redesign

[mfateev]

Activity timeouts are are complicated to give full control over activity failure and retry behavior.
There are two issues with the current design:

1. Activity ScheduleToClose doesn't make sense when RetryPolicy.expiration is specified.
2. By default activities are not retried which is not intuitive for the new users as well as not desired behaviour in 99.9% of use cases.

The strawman redesign proposal:

• Change all timeouts from InSeconds to some real time intervals. The service still can have internal resolution restrictions (like currently 1 second). But we can relax some of that in the future without API changes.
• Merge retry policy into ScheduleActivityTaskDecisionAttributes.
• Remove ExpirationIntervalInSeconds and always use ScheduleToClose timeout instead
• As MaximumAttempts becomes always present assume that its default 0 ("unlimited attempts") means that by default an activity is retried up to ScheduleToClose timeout.
• To "at most once" activity execution (current default) can be achieved by setting the MaximumAttempts to 1.
• Default other fields of retry policy to (subject to discussion or even becoming part of the service configuration)
  • InitialRetryInterval to 1 second
  • MaximumRetryInterval to 90 * InitialRetryInterval
  • ExponentialCoefficient to 2