Use git repo rather than cluster state in release calculations

[squaremo]

When we do an automation run, we compare the state of the cluster to the available images, then apply the differences to the git repo. This mostly does what you'd want in practice, but it relies on the cluster state being mostly equal to what's in the git repo, and that is not always the case.

For example, this sequence is possible:

1. the image DB sees a new tag :v2 for an image and fetches its metadata;
2. the automator looks at the cluster, and sees that it is running :v1, and there is a new image :v2 available;
3. the automator commits a change that updates the image to :v2 and pushes it upstream;
4. the commit is fetched from the upstream repo;
5. the automator looks at the cluster, and sees that it is running :v1, and there is a new image :v2 available;
6. the automator tries to commit a change but there is no change to be made.

Usually this is harmless, but occasionally, if other things get changed at the same time, it will result in some bogus annotations (and therefore bogus events).

Instead, it would be better if the automation (and push-button releases) looked at the config as given by the git repo, and only used the cluster state to determine whether operations are safe to go ahead.

[jml]

What's the status on this? @aaron7 thinks there's been recent progress.

This is the last open issue in the Deploy onboarding project.

[squaremo]

(This is now done for automated releases, but not for push-button releases, so keeping it open.)

[kingdonb]

This behavior is now wholly different in Flux v2, and likely won't be fixed any further in the context of Flux v1 maintenance mode.