fix(perf): Unexpanding pipeline without StageContext (spinnaker#3307)

When calling the following endpoint: `v2/applications/{}/pipelines` with `expand=false`
the `TaskController` will try "unexpand" the pipelines by removing "context" from all the stages.
However, there is a wrinkle: during removal of the context we want to preserve the `group` key (if it exists).
In order to check if the key is there, we make a call to `context.group`. The problem is that the `context` is actually a
`StageContext` and the `.group` is actually a `StageContext::get("group")`.
This particular call traverses the entire execution graph to see if `group` exists not only in the current stage context
but also in the outputs of any of it's parent stages. Well, if the stage graph is large this is a O(n^2) operation.

The kicker is that the `group` should never occur in the outputs (and if it does we don't care).
This stage replaces the implicit groovy call to `.get` with explicit call to `.containsKey` which doesn't traverse the stage hierarchy.

The result (on a 300 stage Kayenta canary pipeline):
Before: 17.2s to fetch the last 2 executions
After:   0.2s to fetch the last 2 executions

feat(sql): add support for a secondary sql execution repo (spinnaker#…

…3302)

This makes it possible to conditionally create a secondary SqlExecutionRepository,
pointing at a specific named connection pool.

This also makes it possible to look up beans in DualExecutionRepository by name,
not just by class, which comes in handy when we want 2 SqlExecutionRepository beans.

fix(monitoreddeploy): unset pinMinimumCapacity when scaling to 100% (s…

…pinnaker#3294)

fix(cloudformation): Support Cloudformation templates as lists (spinn…

…aker#3270) (spinnaker#3277)

Something has changed between Spinnaker 1.15.6 and 1.16.0 with regard to how Cloudformation templates entered into the inline editor in Deck are parsed. Updating Orca to account for this change.

fix(cloudformation): Support Cloudformation templates as lists (spinn…

…aker#3270) (spinnaker#3276)

Something has changed between Spinnaker 1.15.6 and 1.16.0 with regard to how Cloudformation templates entered into the inline editor in Deck are parsed. Updating Orca to account for this change.

fix(notifications): Fix regression from spinnaker#3280 (spinnaker#3284)

spinnaker#3280 introduced a regression where if there are multiple notifications
and the exeuction has SCM info (e.g. jenkins trigger) the pipeline notifications won't get sent out.

Why you ask? Side-effects, my friends!

`contextParameterProcessor.process` actually MUTATES the context that is passed in (it extracts the scm info which starts out as a list and then replaces it with an actual SourceControl object :mindblown:)
see https://github.com/spinnaker/orca/blob/master/orca-core/src/main/java/com/netflix/spinnaker/orca/pipeline/util/ContextParameterProcessor.java#L170
I wanted to not jackson map the whole execution every single notification we eval so I cached and there-in lay my mistake...

This change, does not reuse the executionContext map avoiding this problem

feat(expressions): add ability to query expression capabilities (spin…

…naker#3273)

* feat(expressions): add ability to query expression capabilities

This will be used by `deck` to provide nice auto-complete for end-users typing out SpEL expressions

The endpoint (`/capabilities/expression`) will return
* a list of supported expression spel evaluators (currently v3 only)
* a list of functions and their descriptions&parameters so that `deck` can consume in autocomplete lists
  Note: all functions (including those from the plugins will be returned)
  Also note that implied `Execution` parameters will be stripped as they are not needed for the end-user to understand

Here is an example response:
```
{
  "functions": [
    {
      "name": "stage",
      "description": "Locates a stage by name",
      "parameters": [
        {
          "name": "idOrName",
          "description": "The name or id of the stage to find",
          "type": "String"
        }
      ],
      "documentation": {
        "documentation": "The most common use of this function is to check if a particular stage has succeeded or failed, but it can also be used to retrieve any information about a stage.",
        "examples": [
          {
            "usage": "#stage('bake').hasSucceeded",
            "description": "Returns true if the stage with the name `bake` has succeeded"
          },
          {
            "usage": "#stage('bake').hasFailed",
            "description": "Returns true if the stage with the name `bake` has failed"
          }
        ]
      }
    },
    ...
  ]
  "spelEvaluators": [
    {
      "versionKey": "v3",
      "description": "some description"
    }
  ]
}
```

Depends on spinnaker/kork#410 and co-exists with `gate` PR which is TBD

* fixup! feat(expressions): add ability to query expression capabilities

feat(monitoreddeploy): allow overriding maxAnalysisMinutes and failOn…

…Error (spinnaker#3261)

Allow overriding these values from within the stage

feat(monitoreddeploy): allow overriding maxAnalysisMinutes and failOn…

…Error (spinnaker#3261)

Allow overriding these values from within the stage

feat(script stage): set a context value REPO_URL after starting a scr…

…ipt job (spinnaker#3267)

The current implementation of the SCRIPT stage using Jenkins requires that the remote URL of the script be set to something like mystashrepo/${REPO_URL}.

Jenkins currently returns the unprocessed remoteURL, and this value causes a SPEL warning when SPEL tries to resolve this value.

This fix will populate the REPO_URL value in the context, which allows the SPEL expression to evaluate and the warning to disappear