Make Installation Target objects auto-contained

[isutton]

Objectives

The main object is to make the Installation Controller able to converge to an
installation target desired state independent of the role its Release object has
according to the current Application description (past releases, latest
incumbent, contender or currently active).

Another objective is to make the installation target object richer than it
currently is by including all information required to render and install the
Application's associated chart; this would enable a Shipper user to create
standalone installation target objects and Shipper would still try to converge
to its desired state.

Proposed Changes

shipperv1.InstallationTarget Changes

To achieve the objectives stated earlier in this document,
InstallationTargetSpec.Clusters should be changed from []string to a richer
type ClusterInstallationSpec representing each cluster installation target
specification, like the following type specification:

package v1

type ClusterInstallationSpec struct{
   CanOverride bool           `json:"canOverride,omitempty"`
   Chart       v1.Chart       `json:"chart"`
   Values      v1.ChartValues `json:"values,omitempty"`
}

• canOverride bool: Informs the Installation Controller it should override
  existing Kubernetes objects that were previously created by another installation
  target object. The default value is false.

• values shipperv1.ChartValues: The values that should be informed when
  rendering the chart. This field should be informed by Shipper at the time the
  installation target object is created.

• chart shipperv1.Chart: Required chart information that will be used to
  render the objects that will be installed on the application cluster. This field
  should be informed by Shipper at the time the installation object is created.

Installation Controller Changes

When rendering the Kubernetes objects contained in the specified chart, the
Installation Controller should include the shipper-owned-by label with its
value being the identity of the installation target object that resulted on
the installation.

When proceeding to install the rendered Kubernetes objects on a specific
application cluster, the Installation Controller should check a) the identity
of the installation target object that lastly modified the object and b)
whether canOverride is enabled. With this two pieces of information, the
controller can properly decide whether it is allowed to override existing
objects that were lastly modified by another installation target object. In the
case where an installation target object overrides an existing Kubernetes
object in the application cluster that wasn't lastly modified by itself, the
installation controller will replace the shipper-owned-by label's value with
its own identity.

After those changes are implemented, the Installation Controller should not
use any heuristics based on the current installation target object's related
Release role (past releases, incumbent, contender or currently active).

The installation target object Ready condition should be updated accordingly:
in case of partial installation (canOverride is set to false, and
shipper-owned-by label specifies a different installation target object)
the condition's status should be set to False, with OverrideNotAllowed
as reason. This should be used to block any further actions using the
installation target as input (for example, proceeding to the next slice on the
current Release strategy's step).

Strategy Controller Changes

The Strategy Controller should orchestrate transitions by updating the related
installation target's ClusterInstallationSpec.canOverride to the appropriate
values (those operations should be performed per cluster):

• Initial Release: canOverride is set to true.
• Before transition: incumbent's canOverride is true, contender's is false.
• After contender's installation is finished: incumbent's canOverride is
  false, contender's is true. This transfers the control over to the
  contender Release's installation target object, allowing the Installation
  Controller to override any offending objects.

The Strategy Controller's "installation, capacity and traffic" loop should now
respect the "installation" aspect of it; this means that a strategy step can
potentially be stuck until the Ready condition is set to True.