v0.8.0-alpha.1: Release StrategyExecutor aborts if successor release is progressing

This release is a fix of a problem with the new implementation of the
reconciliation loop involving strategy execution for all release (as
opposed to apply it to contender-incumbent pair only in the old
implementation). The problem we observed boiled down to the next
scenario:
  1. A contender runs through the strategy execution loop and bails out
  with an incomplete state.
  2. Incumbent enters it's independent strategy loop and checks it's
  desired state from the desired state of the contender. This is the
  point where the things broke: desired state != achieved state. At this
  moment incumbent can start progressing without waiting for it's
  successor (contender) to complete.

This optimistic triggering was not a planned action and was mainly
mistakenly introduced because distinct release generations are being
processed independently now.

Preventing the strategy loop from progressing is one way to get around
this problem where releases are being processed independently. Another
alternative to that could be: an incumbent release can be smarter in
terms of figuring out it's desired state itself (e.g. if it's successor
hasn't achieved it's target step yet, try to reconcile on the last
step in it's own strategy). This behavior has pros and cons of course.
On the bright side: releases can behave much more independently and this
can also challenge the need for incumbent and contender strategy states.
On the lowlight, this might provoke some unwanted chatting and flapping
in the release squad. Chatty releases might be quite expensive in terms
of converging to a stable state (as we now provoke a direct and reverse
chain reaction when there is a change to a release object).

For now, we settle down with an easy patch which prevents the system
from doing unwanted things. This approach might be a subject for change
in the future.

Signed-off-by: Oleg Sidorov <oleg.sidorov@booking.com>

v0.8.0-alpha.0

Changelog for Shipper v0.8

v0.7.0-beta.0: TrafficController enqueues all TrafficTarget objects on changes

The mechanics of the bug indicated by the unit test boils down to the
following: traffic controller ensures to bring traffic targets to the
desired state but once a contender tt has been scaled up, the incumbent
tt is being scaled down. This implies on rebalancing the weights of tt's
but none of the observant objects (neither tt nor pods) are effectively
changing on contender side: only on incumbent.

What this patch promotes is: traffic controller reacts to traffic target
changes and enqueues all known traffic targets for this application.
This guarantees converging on the weight balance under conditions of
non-changing objects.

Signed-off-by: Oleg Sidorov <oleg.sidorov@booking.com>

v0.7.0-alpha.3: TrafficController enqueues all TrafficTarget objects on changes

The mechanics of the bug indicated by the unit test boils down to the
following: traffic controller ensures to bring traffic targets to the
desired state but once a contender tt has been scaled up, the incumbent
tt is being scaled down. This implies on rebalancing the weights of tt's
but none of the observant objects (neither tt nor pods) are effectively
changing on contender side: only on incumbent.

What this patch promotes is: traffic controller reacts to traffic target
changes and enqueues all known traffic targets for this application.
This guarantees converging on the weight balance under conditions of
non-changing objects.

Signed-off-by: Oleg Sidorov <oleg.sidorov@booking.com>

v0.7.0: TrafficController enqueues all TrafficTarget objects on changes

The mechanics of the bug indicated by the unit test boils down to the
following: traffic controller ensures to bring traffic targets to the
desired state but once a contender tt has been scaled up, the incumbent
tt is being scaled down. This implies on rebalancing the weights of tt's
but none of the observant objects (neither tt nor pods) are effectively
changing on contender side: only on incumbent.

What this patch promotes is: traffic controller reacts to traffic target
changes and enqueues all known traffic targets for this application.
This guarantees converging on the weight balance under conditions of
non-changing objects.

Signed-off-by: Oleg Sidorov <oleg.sidorov@booking.com>

v0.7.0-alpha.2: Release executor returns a sorted list of unready clusters

Release executor is reported to return an unstable sorting of clusters
that are pending capacity updates. This causes some unnecessary etcd
update operations and pollute the logs. This commit forces stable
sorting of this list.

Signed-off-by: Oleg Sidorov <oleg.sidorov@booking.com>

v0.7.0-alpha.1: Do not retry RolloutBlock not found errors

Signed-off-by: Oleg Sidorov <oleg.sidorov@booking.com>

v0.7.0-alpha.0: installer: resolve some ownership issues

This resolves two seemingly unrelated issues, but since they both
required changing the same bit of code, I'm combining it into the same
commit.

1. Shipper shouldn't update objects that it didn't create, or that it
created for a different application that happened to have objects with
the same names. This was reported in #98 [1]. If it finds such objects,
it should bail out and let the user know, as it's not possible for
shipper to resolve this on its own.

2. After we removed the migration scaffolding in
9967c55ca22bf013dfe9de25846a297ecd3ad7fe, we didn't account for k8s
objects that might've been left behind from apps that didn't get any new
releases while running shipper v0.6, particularly services. Those would
fail with the following error:

	Object "foo/bar" is missing required label "shipper-owned-by" as
	it was not created by any InstallationTarget. Shipper doesn't
	know how to deal with this

Note how you can't know which Kind we're talking about :) This has also
been addressed in this commit.

[1] https://github.com/bookingcom/shipper/issues/98 - Only replace the
services created by this Application object

v0.6.0-beta.2: shipper: don't lie about webhook's identity

The webhook was getting a client that had rolloutblocks controller as
its user agent. Even though rollout blocks were indeed what the client
was being used for, that's not guaranteed to stay true forever. So let's
make sure we give the webhook a client tied to its own identity.

v0.6.0-beta.1: shipper: don't lie about webhook's identity

The webhook was getting a client that had rolloutblocks controller as
its user agent. Even though rollout blocks were indeed what the client
was being used for, that's not guaranteed to stay true forever. So let's
make sure we give the webhook a client tied to its own identity.