Generate CRD Schemas

[Harwayne]

Problem
Most of our CRDs reuse the same underlying structs for common functionality. For example, most sources contain spec.pubSubSpec. However, each CRD's YAML must contain its own OpenAPIV3Schema.

We should have a tool that makes it easy to use a common schema 'snippet' for these shared types.

Persona:
Developer

Exit Criteria

• A developer can add a field or extra OpenAPI schema validation to an existing field that is used by multiple types without having to manually alter the YAML for every CRD that uses that type.
  • E.g. I add extra schema validation to spec.pubSubSpec.foo. That field is used by a dozen sources. I do not have to update a dozen YAML files. Instead I only need to update one.

Additional context (optional)
This need became apparent while working on #614 and #615. While working on those, I noticed that almost every Source had a slightly different schema for the commonly shared types. Even more fun was that they sometimes were at different levels of nesting, so copy-pasting was difficult and error prone.

[Harwayne]

Possible solutions:

1. kustomize
   • This seems to be the way that K8s is pushing to modify YAMLs before applying them.
   • This directory shows how it can be done for CloudAuditLogsSource.
     • I think it is fairly ugly and probably require code duplication to inject the same schema at distinct levels.
2. ytt
   • I've seen interest in this from others in Knative, particularly around test and release.
   • I think we can get this to work, but it would require a distinct file for the entire node (e.g. properties.yaml) and annotate all the entries in 'pubsub_spec' with #@overlay/match missing_ok=True.
3. yq
   • I think I could get yq to work via its create and merge operators.
4. Custom tool.
   • See CRD Generation #919. This is what I used to generate the YAMLs for Conversion, store and serving of v1beta1 APIs #615.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.