Summary

As a developer of cluster log forwarding,
I want invalid custom resources to be rejected by the API server
so the validation and status logic is simplified

Acceptance Criteria

• Verify the existing validations block admission of a cluterlogforwarder
• Verify users receive feedback for failed admissions (status?)

Notes

• How will this affect partially correct CRs during upgrade scenarios? We currently normalize CLF and add status to which bits were dropped
• This change could involve refactoring the verification logic to be associated with outputs in lieu of one large verification function