CRD validation blocking requests with tlsConfig

[a904852]

What happened?

Creating a DisposableRequest with tlsConfig violates the validation rule: insecureSkipTLSVerify and tlsConfig are mutually exclusive. That happens even when insecureSkipTLSVerify is not set.

How can we reproduce it?

apiVersion: http.crossplane.io/v1alpha2
kind: DisposableRequest
metadata:
  name: test-secret-fetch
spec:
  deletionPolicy: Orphan
  forProvider:
    method: GET
    url: https://REDACTED/api/v1/namespaces/default/secrets/test-secret
    headers:
      Content-Type:
        - application/json
    tlsConfig:
      caCertSecretRef:
        name: api-ca
        namespace: default
        key: ca.crt

Rule violation at admission: The DisposableRequest "test-secret-fetch" is invalid: spec.forProvider: Invalid value: "object": no such key: insecureSkipTLSVerify evaluating rule: insecureSkipTLSVerify and tlsConfig are mutually exclusive

apiVersion: http.crossplane.io/v1alpha2
kind: DisposableRequest
metadata:
  name: test-secret-fetch
spec:
  deletionPolicy: Orphan
  forProvider:
    method: GET
    url: https://REDACTED/api/v1/namespaces/default/secrets/test-secret
    headers:
      Content-Type:
        - application/json
    insecureSkipTLSVerify: false
    tlsConfig:
      caCertSecretRef:
        name: api-ca
        namespace: default
        key: ca.crt

Rule violation in status

status:
  conditions:
  - lastTransitionTime: "2026-03-09T10:35:42Z"
    message: 'cannot update managed resource: DisposableRequest.http.crossplane.io
      "test-secret-fetch" is invalid: spec.forProvider: Invalid value: "object": no
      such key: insecureSkipTLSVerify evaluating rule: insecureSkipTLSVerify and tlsConfig
      are mutually exclusive'
    observedGeneration: 1
    reason: ReconcileError
    status: "False"
    type: Synced
  requestDetails:
    method: ""
    url: ""
  response: {}

What environment did it happen in?

Crossplane version: 1.20.0
Provider version: 1.0.13

[a904852]

Essentially the rule: '!(self.insecureSkipTLSVerify == true && has(self.tlsConfig))' does not check for the existence of insecureSkipTLSVerify.
When it's present the admission passes but is later violated during status update.
When it's not present the validator gets a "no such key" error.