feat: support conversions in XRDs

[phisco]

Description of your changes

Fixes #2608.

Adds the ability to configure the Conversion strategy of the resulting CRD, allowing users to define multiple versions with different schemas.

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable to ensure this PR is ready for review.
• Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xpostgresqlinstances.database.example.org
spec:
  conversion:
    strategy: Webhook
    webhook:
      conversionReviewVersions: ["v1","v1beta1"]
      clientConfig:
        service:
          namespace: default
          name: example-conversion-webhook-server
          path: /crdconvert
  group: database.example.org
  names:
    kind: XPostgreSQLInstance
    plural: xpostgresqlinstances
  claimNames:
    kind: PostgreSQLInstance
    plural: postgresqlinstances
  connectionSecretKeys:
    - username
    - password
    - endpoint
    - port
  versions:
  - name: v1
    referenceable: true
    served: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            description: "The OpenAPIV3Schema of this Composite Resource Definition."
            properties:
              parameters:
                type: object
                properties:
                  storageGB:
                    type: integer
                    description: "The desired storage capacity of the database, in GB."
                  newEngine:
                    type: string
                required:
                  - storageGB
            required:
              - parameters
  - name: v1beta1
    served: true
    referenceable: false
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            description: "The OpenAPIV3Schema of this Composite Resource Definition."
            properties:
              parameters:
                type: object
                properties:
                  storageGB:
                    type: integer
                    description: "The desired storage capacity of the database, in GB."
                  oldEngine:
                    type: string
                required:
                  - storageGB
            required:
              - parameters

Results in the following CRD:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  creationTimestamp: "2023-04-04T09:34:47Z"
  generation: 3
  name: xpostgresqlinstances.database.example.org
  ownerReferences:
  - apiVersion: apiextensions.crossplane.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: CompositeResourceDefinition
    name: xpostgresqlinstances.database.example.org
    uid: b0b11311-123c-4287-80dd-7f005ae72a11
  resourceVersion: "916740"
  uid: d1740fac-92d8-42e4-8c79-b28c3260e434
spec:
  conversion:
    strategy: Webhook
    webhook:
      clientConfig:
        service:
          name: example-conversion-webhook-server
          namespace: default
          path: /crdconvert2
          port: 443
      conversionReviewVersions:
      - v1
      - v1beta1
  group: database.example.org
  names:
    categories:
    - composite
    kind: XPostgreSQLInstance
    listKind: XPostgreSQLInstanceList
    plural: xpostgresqlinstances
    singular: xpostgresqlinstance
  scope: Cluster
  versions:
  - additionalPrinterColumns:
    - jsonPath: .status.conditions[?(@.type=='Synced')].status
      name: SYNCED
      type: string
    - jsonPath: .status.conditions[?(@.type=='Ready')].status
      name: READY
      type: string
    - jsonPath: .spec.compositionRef.name
      name: COMPOSITION
      type: string
    - jsonPath: .metadata.creationTimestamp
      name: AGE
      type: date
    name: v1
    schema:
      openAPIV3Schema:
        properties:
          apiVersion:
            type: string
          kind:
            type: string
          metadata:
            type: object
          spec:  # { ... OMITTED ... }
    served: true
    storage: true
    subresources:
      status: {}
  - additionalPrinterColumns:
    - jsonPath: .status.conditions[?(@.type=='Synced')].status
      name: SYNCED
      type: string
    - jsonPath: .status.conditions[?(@.type=='Ready')].status
      name: READY
      type: string
    - jsonPath: .spec.compositionRef.name
      name: COMPOSITION
      type: string
    - jsonPath: .metadata.creationTimestamp
      name: AGE
      type: date
    name: v1beta1
    schema:
      openAPIV3Schema:
        properties:
          apiVersion:
            type: string
          kind:
            type: string
          metadata:
            type: object
          spec: # { ... OMITTED ... }
    served: true
    storage: false
    subresources:
      status: {}
status:
  acceptedNames:
    categories:
    - composite
    kind: XPostgreSQLInstance
    listKind: XPostgreSQLInstanceList
    plural: xpostgresqlinstances
    singular: xpostgresqlinstance
  conditions:
  - lastTransitionTime: "2023-04-04T09:34:47Z"
    message: no conflicts found
    reason: NoConflicts
    status: "True"
    type: NamesAccepted
  - lastTransitionTime: "2023-04-04T09:34:47Z"
    message: the initial names have been accepted
    reason: InitialNamesAccepted
    status: "True"
    type: Established
  storedVersions:
  - v1

[negz]

Two non-blocking comments, but otherwise this LGTM.

Do we want to back port it to v1.11.x though? I would argue no - this feels like a new feature rather than a bug fix.

[negz]

Should we use the extv1 type here, or define our own?

I'm thinking we may want to support strategies that upstream doesn't support in future, for example some kind of declarative conversion. I suppose we could always switch from upstream's type to our own at that point.

[phisco]

Yes, I also had the same doubt, in the end I chose extv1 because I thought it was better to effortlessly support everything they might introduce upstream, and as you said, we can always switch to our own later on if needed. But I'm ok switching to our own if you feel we want to have more control.

[turkenh]

we can always switch to our own later on if needed.

@phisco can you validate that this is possible without changing (i.e. breaking) the API? If possible, we can go with extv1 for now and consider this later.

[phisco]

On the CRD side there won't be changes, except the desired ones, nor aliasing the type to add some methods, nor embedding with json:",inline" to add additional fields, nor completely duplicating the struct.

[jbw976]

Do we want to back port it to v1.11.x though? I would argue no - this feels like a new feature rather than a bug fix.

Agreed, I would also like to let this bake in main branch for a bit and then be initially released in v1.12 as opposed to being backported for a patch release.