Add release spec format to selectively update containers in resources

[rndstr]

This adds a new release spec format providing update requests on container
level.

Sample POST request body to /v9/update-manifests:

{
  "type": "containers",
  "cause": {
    "Message": "sample request body",
    "User": "alice"
  },
  "spec": {
    "ContainerSpecs": {
      "default:deployment/nginx": [
        {
          "Container": "nginx",
          "Current": "nginx:1.14.0",
          "Target": "nginx:1.15.0"
        }
      ],
      "default:deployment/helloworld": [
        {
          "Container": "helloworld",
          "Current": "quay.io/weaveworks/helloworld:master-07a1b6b",
          "Target": "quay.io/weaveworks/helloworld:master-a000004"
        },
        {
          "Container": "sidecar",
          "Current": "quay.io/weaveworks/sidecar:master-a000001",
          "Target": "quay.io/weaveworks/sidecar:master-a000002"
        }
      ]
    },
    "Kind": "plan",
    "IgnoreMismatches": false
  }
}

The request will fail if any of the Current container image requirements
are not met or containers cannot be found. To have partial updates go
through and ignore any failures, one can pass true for IgnoreMismatches.

Also, Current can be left empty to disable any precondition check.

Closes #1140

[squaremo]

The request will fail if any of the Current container image requirements
are not met. To have partial updates go through and ignore the failed
requirements, one can pass true for IgnoreFailedControllers.

This suggests that the it's only failing to meet the precondition (Current field) that can be excused by IgnoreFailedControllers; but it looks like it's also other failures, e.g., a container being missing entirely.

It seems to me that these are qualitatively different kinds of failure: failing to meet the precondition means you have an out-of-date spec, but failing to name the right containers means you have an incorrect spec.

I'm not totally sure how this will be used, so I'd appreciate a rationale for how it works, in particular,

• why is it useful to be able to ignore a part of the update that names a missing container?
• should it fail overall if you are ignoring failures, but nothing is successful?

An alternative would be to not supply a precondition, if you don't have one -- and all preconditions that have been supplied must be met, to succeed overall. But again, I'm not sure of the intended use, so this may be less suitable.

[squaremo]

I've reread #1140 and I understand a bit better what the purpose of IgnoreFailedControllers is -- it's to address this bit, I think:

You might find that, for example, releases can hardly ever succeed, because something always changes before you hit the button. In that case it would be useful to be able to relax the all-or-nothingness

In that case, I reckon it should switch between the mode of "succeed only if all preconditions are met" and "succeed for all containers where the preconditions are met, leave others as they are".

Unconditionally updating containers (being able to not supply a precondition) is a different matter -- sorry for the distraction -- though may in itself be useful, I don't know.

[rndstr]

@squaremo yes, I adjusted the logic a bit to make things clearer with regard to failed/skipped states.

It's either

• only update if all preconditions match (default)
• update all containers whose preconditions match (IgnoreMismatches–open to renaming)
• skip preconditions (don't provide them)

[squaremo]

Misnamed containers should be outright failures.
Other stuff is just advisory :-)

[squaremo]

Looks good, let's give it a go 😄

git rebase -i master to get rid of the feedback commits, depending on your personal attitude towards git neat-and-tidiness (and present level of busyness).

[squaremo]

Extra approval for extra commit

[jpellizzari]

@rndstr To which endpoint does one do the POST and with what URL params, if any?

[rndstr]

@jpellizzari /v9/update-manifests; no URL params, all the options are in the JSON body