Name a release's steps in the releaseGate element, so the gate does not infer them #240

What

The releaseGate element names an Application's members and says nothing of the steps that come before them: its migration and its prepare Processes (chapter 55, Release order). The Release Gate answers may-start only once those have completed, so it has to know which they are.

Today it reads them off the cluster (JorisJonkers-dev/delivery#2): every identity that has ever run a release Job of the Application is a step, and its Job of this revision must be there and complete. That holds for every release but one. An Application's first migration has no earlier Job, so until its Job is applied the gate sees an Application with no steps and answers yes.

What to decide

Whether the releaseGate element carries the release's steps, for instance the identities whose Job of the revision must complete, so the gate reads what must happen from the render instead of inferring it from what has happened.

It would also be what the full gate (JorisJonkers-dev/delivery#3) starts: it unsuspends those Jobs, and needs their names from somewhere it can trust.

Acceptance criteria

• Chapter 20's release-gate table says whether the steps are an input, and chapter 55 says what may-start reads.
• If they are: both implementations write them, the ConfigMap carries them, and the gate refuses a release whose step has no Job.

Part of #195. Follows JorisJonkers-dev/delivery#2.