Enable conversion webhook for test suites

[programmer04]

Problem Statement

Spinoff of

• feat: introduce conversion webhook machinery, register ControlPlane, GatewayConfiguration CRDs #1959

Read the description for more context.

Conversion webhook is enabled by default for the controller, but in test suites e.g. integration, it's disabled.

The missing piece is ensuring that cert-manager is in place to allow TLS connections between the K8s cluster's control plane and the KO controller.

Enhance the machinery of running those suites to include all the stuff required for the webhook to run, to be able to cover it with some integration tests too.

It probably makes sense to do it when KO will have well-defined test suites

Acceptance Criteria

• identify test suites that should be run with webhook enabled
• allow running them with webhook enabled

[programmer04]

Conversion webhook is triggered only for specific types (which are deprecated), so having it enabled for all of the test suites is pointless, because other resources than those registered for conversion, currently

• ControlPlane from gateway-operator.konghq.com/v1beta1
• KonnectGatewayControlPlane from konnect.konghq.com/v1alpha1

are not triggering the conversion webhook. Thus, only two e2e tests are enough to test it end-to-end with configurations

1. Scenario to run for ControlPlane from gateway-operator.konghq.com/v1beta1

   apiVersion: gateway-operator.konghq.com/v1beta1
   kind: DataPlane
   metadata:
     name: dataplane-cp-watchnamespace
     namespace: default
   spec:
     deployment:
       podTemplateSpec:
         spec:
           containers:
           - name: proxy
             image: kong:3.9
             env:
             - name: KONG_LOG_LEVEL
               value: debug
             resources:
               requests:
                 memory: "64Mi"
                 cpu: "250m"
               limits:
                 memory: "1024Mi"
                 cpu: "1000m"
             readinessProbe:
               initialDelaySeconds: 1
               periodSeconds: 1
   ---
   apiVersion: v1
   kind: Namespace
   metadata:
     name: namespace-a
   ---
   apiVersion: gateway-operator.konghq.com/v1alpha1
   kind: WatchNamespaceGrant
   metadata:
     name: watchnamespacegrant
     namespace: namespace-a
   spec:
     from:
     - group: gateway-operator.konghq.com
       kind: ControlPlane
       namespace: default
   ---
   apiVersion: gateway-operator.konghq.com/v1beta1
   kind: ControlPlane
   metadata:
     name: controlplane-example
     namespace: default
   spec:
     dataplane: dataplane-cp-watchnamespace
     gatewayClass: kong
     watchNamespaces:
       type: list
       list:
       - namespace-a
     deployment:
       podTemplateSpec:
         metadata:
           labels:
             controlplane-pod-label: example
         spec:
           containers:
           - name: controller
             image: kong/kubernetes-ingress-controller:3.5.0
             readinessProbe:
               initialDelaySeconds: 1
               periodSeconds: 3
             resources:
               requests:
                 memory: "64Mi"
                 cpu: "250m"
               limits:
                 memory: "1024Mi"
                 cpu: "1000m"

2. Scenario to run for KonnectGatewayControlPlane from konnect.konghq.com/v1alpha1

   kind: KonnectGatewayControlPlane
   apiVersion: konnect.konghq.com/v1alpha1
   metadata:
     name: test
   spec:
     # source: Origin
     name: test-demo-cp-e2e
     konnect:
       authRef:
         name: konnect-api-auth-dev
   ---
   kind: KonnectAPIAuthConfiguration
   apiVersion: konnect.konghq.com/v1alpha1
   metadata:
     name: konnect-api-auth-dev
   spec:
     type: token
     token: kpat_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
     serverURL: us.api.konghq.tech

Both scenarios should succeed, and they can be implemented as soon as the chainsaw machinery is ready, see for more context

• feat(testing): Bootstrap hybrid gateway e2e tests with chainsaw #2725