Rollback of gateway subsystem to v2018

If the upgrade from v2018 to v10 does not succeed, you can rollback the gateway subsystem to v2018.

About this task

The upgrade CR has an optional property triggerRollback which provides the ability to define when a rollback should or should not) be initiated. The triggeRollback property can take the following values:

Value	Description
`false`	Rollback of the gateway subsystem will not be triggered. Default value
`true`	The upgrade of the gateway subsystem will be rolled back immediately unless the upgrade process has already moved to a status condition of `Complete`. The upgrade CR is rejected if `triggerRollback` is set to `true` on creation.

You can rollback the gateway subsystem upgrade during the upgrade's dual backend phase, but not during the single backend phase:

Dual backend phase
- The first part of the process uses a dual backend. The gateway upgrade starts by checking the replica count of the v2018 Gateway to set it as target for the upgraded v10 gateway. The v2018 StatefulSet is scaled down by one, and the v10 Gateway is set to one replica.
  
  While the first v10 replica is starting, the api request traffic as well as admin traffic is only routed to v2018. Once the first v10 gateway pod is ready, admin traffic is routed to the v10 gateway, and a syncDelaySeconds timer is used to allow the first v10 gateway to synchronize with the API Connect Management subsystem.
  
  After this delay, api traffic is routed to both v2018 pods and the first v10 pod. v2018 StatefulSet is then progressively scaled down, while the v10 StatefulSet is scaled up to reach the target replicas matching the initial v2018 subsystem. Once the v2018 replicas is 0, the api traffic is only routed to v10 Gateway (admin remains routed only to v10 as well). The upgrade CR transitions then to "single backend".
  
  While this dual backend upgrade is happening, it is possible to update the upgrade CR to add a value triggerRollback: true which will remove the v10 StatefulSet and scale back the v2018 StatefulSet to its initial replica count. The api and admin traffic is then also only routed to v2018 pods.
Single backend phase
Once the target replica for v10 is reached, the v2018 artifacts are deleted, and the upgrade CR transitions then to Complete. During this single backend phase, you cannot trigger a rollback.

Procedure

Ensure that the state of upgrade CR has not reached the Complete status.
Specify the rollback in the upgrade CR:
1. Edit the upgrade CR:
```
kubectl edit up2018g <upgrade_cr_name> -n <namespace>
```
2. Change the triggerRollback value to true:
```
triggerRollback: true
```
  When the upgrade was rolled back, then after the v2018 resources are scaled back to the initial replicas and the v10 resources are deleted, the upgrade CR is marked RollbackComplete.