Reject release modifications in the validating webhook

[parhamdoustdar]

To improve user experience and prevent user errors, our validating webhook should do the following things.

• For updates, it should make sure that the field which is modified is not the spec.environment
• If the release is not being rolled out, all the changes to the targetStep must be rejected

We had an incident where a user modified the spec.environment of an older Release object. A Release got created as a result, but since hits is not a code path that we exercise, somehow two Releases ended up with the same release generation. As a result, Shipper started creating Release objects in a loop, because the Application's spec didn't match the spec.environment of the Release.

[ghost]

For updates, webhook should also allow changes in annotation in order to override, or remove overrides, of rollout blocks

[parhamdoustdar]

I edited the issue so that it covers the point you raised. Thanks a lot for the great catch!