fix(RRB): Do not consider traffic guards during RRB deploy (spinnaker…

…#3054)

As a result of spinnaker#3037, the RRB flow now no longer bypasses traffic guards
(it used to do that before, here: https://github.com/spinnaker/orca/blob/master/orca-clouddriver/src/main/groovy/com/netflix/spinnaker/orca/clouddriver/tasks/cluster/AbstractClusterWideClouddriverTask.groovy#L145 `shouldSkipTrafficGuards`.)

Instead, now when we run the first disable step in RRB (e.g. disable 5% of source), the traffic guards think
the whole ASG is going away as it is unaware of the percentage disable flag and thus it terminates the operation
since "disabling entire ASG while new is still not fully up" is most certainly unsafe.

For now, add back the logic we had in the `AbstractClusterWideTask` to `DisableServerGroupTask` to skip check on RRB deploys.
In the future, we should not have artisanal checks like this and instead have traffic guards understand that
a percentage of an ASG is going away and validate against that percentage.

feat(queue): shovel support going to/from redis cluster (spinnaker#3053)

fix(RRB): fix NPE introduced in spinnaker#3031 (spinnaker#3050)

When there is no source server group and a validation pipeline has been specified
RRB flow composition will fail (erroneously) trying to construct parameters to be
passed into the validation pipeline (even though the source isn't even necessary!).

This fix does two things:
1. Correctly calculate parameters passed into the validation pipeline
2. Don't even bother composing the flow if we are being called during the `beforeStages`
   since all these stages will be discared anyway (none of the stages have `STAGE_BEFORE` synthetic)

Medium term: all of this should just go away - we shouldn't be using `aroundStages` which is a
source of lots of confusion. I will be refactoring this code to take advantage of newer
`beforeStages` and `afterStages`

fix(webhook): Support verification of redirected urls (spinnaker#3049)

```
public boolean isRedirect() {
    switch (code) {
      case HTTP_PERM_REDIRECT:
      case HTTP_TEMP_REDIRECT:
      case HTTP_MULT_CHOICE:
      case HTTP_MOVED_PERM:
      case HTTP_MOVED_TEMP:
      case HTTP_SEE_OTHER:
        return true;
      default:
        return false;
    }
  }
```

In the event that a redirect is detected, the value of the `Location`
header will be checked against `UserConfiguredUrlRestrictions`.

Can be disabled by setting `webhook.verifyRedirects: false`

feat(redis): redis cluster support for queue and locking (spinnaker#3052

)

- Enables use of Redis Cluster for Orca's queue and distributed lock
service, when SQL is used for the execution repository. Running Orca
entirely on Redis Cluster remains unsupported.

fix(preconfiguredJob): make cluster.application optional (spinnaker#3047

)

fix(webhook): Supply additional context when fetching `RestTemplate` (s…

…pinnaker#3045)

This supports the use-case of needing a specific `RestTemplate`
per url.

feat(webhook): Allow for customization of the default `RestTemplate` (s…

…pinnaker#3044)

fix(RRB): disable traffic on the source server group only (spinnaker#…

…3037)

Make sure RRB disable step disabled the same number of instances as it brought online,
and only in the source server group.

Imagine there are multiple active server groups for RRB:

- v001 (capacity: 6, active)
- v002 (capacity: 10, active)

we are deploying v003, with the following steps: 50%, 100%

Currently, RRB will do the following:
1. Spin up 5 instances in v003 (50% of the source which is v002)
2. Disable 3 instances in v001 and 5 in v002 for a total of 8!
3. Spin up another 5 in v003 (100%)
4. Disable 3 and 5 respectively

Effectively we went from capacity 16 to 10 and are now under provisioned.
This is an edge case, but we want it to have predictable behavior that doesn't leave the cluster under provisioned

chore(queue): log when pending messages found in previous service (sp…

…innaker#3043)