As a WMCO user, I want the api-int CA managed by WMCO so we have happy certificate rollouts for longliving certs.

Description

Currently, WMCO is not managing the api-int CA. We have not run into this yet as the cert is set to rotate every 8 years. However, if the Kube API server operator initiates cert rollouts, then an api-int rotation could be triggered, causing nodes to go NotReady with the kubelets unable to call in their status to an api-int signed by the new CA that they don't trust yet. 

Example error seen when the certs expire:

Nodes go NotReady with kubelet failing to communicate with api-int because of tls: failed to verify certificate: x509: certificate signed by unknown authority. 

Engineering Details

How to trigger a certificate rotation through forced expiry(manual): 

• Find the secret associated with the certificate - api-int CA maps to the apiserver-server-ca secret
  • `oc edit secrets/<name_of_secret> -n <namespace_of_secret>`
• Set the NotAfter field in the secret to “null” and save/exit - forced expiry causes the cert to rotate

GDoc: https://docs.google.com/document/d/1CWgeQcBmsyLK7l48MqBDMAdxBy5rQjoR1lXdnkc8vQQ/edit?usp=sharing 

See the duplicate MCO issue for guidance: https://issues.redhat.com/browse/OCPBUGS-25821 

Acceptance Criteria

• When older clusters(8+ years) update into or run 4.15.0+ and the Kube API server operator initiates the api-int CA rollout, Windows Nodes stay in Ready. 
• When an api-int rotation is triggered through expiry(see how to trigger a cert rotation through forced expiry), Windows Nodes stay in Ready.