Handling multiple controller-side validations #167
Description
#142 introduces a validation step in the reconciler to ensure that any bad semvers that slip through the regex validation on the .spec.version field are still caught before before the resolver is executed. Without this, a resolution error would be thrown saying the regex cannot be parsed. So, it could be that this isn't necessary (although there is some argument to be made about ensuring the input is clean before it reaches the resolver).
The current validation code bails at the first validation failure, stops reconciliation (and doesn't re-enqueue the resource), and adds an InvalidSpec condition to the status. When/if we add additional field validators, we'll need to figure out how we want to present this to the user (and whether we want to run the whole validation suite first and collect all the errors, or still bail at the first one). This leads to a discussion of whether we ought to add multiple conditions of the same type (which doesn't seem like best practice), or put everything into one single condition.