Is your feature request related to a problem? Please describe.

For users who use ramping.
Having upgraded from v1 to v2 and set v2 to current, some users would want to instantly roll back to v1 if they discover an issue.

Can allow users to configure a rollout strategy for rollbacks?

Describe the solution you'd like

Additional context

Currently there is only a rollout strategy.

Could do:

• Check if version is in DeprecatedVersions (still in sunset) and that version was previously a CurrentVersion
  • Temporal server provides LastDeactivationTime and LastActivationTime but those are not enough because they include if the version was only ramping. Check LastCurrentTime != nil to confirm that it was nil.
• If still in sunset, could automatically set to AllAtOnce.
  • No need to intertwine these.
• Do we want to provide a parameter such as "fastRollbackAgeLimit" or just default to 24h?
  • 1 vote for default to 24h
  • Idea here is that a much older version is more likely to be very different from what the running workflows expect.
• Do we want to only support rolling one version back?
  • We can add a limit like this if requested. To start with, any previously-Current version within default of 24h age is eligible for #fastrollback

Open questions:

• If we change LastCurrentTime to be the last time a version was current, instead of the last time a version was set to current, the 24h fastRollbackAgeLimit makes sense. --> Will do in a future server release.

• Should we add a knob for fastRollbackAgeLimit --> yes, and default to 1h

• What should the default rollback strategy be? --> AllAtOnce with a 1h time limit. Disable rollback if rollout mode is manual.

• [Add to a separate doc on rollback] Operator might want to decide to pin all AutoUpgrade workflows that are running on the bad version to the bad version, so that they don't roll back to the previous version. (Or workflow pause?)