Add destinationCACertificate support for OpenShift reencrypt routes

Summary:
Customer (SAQ) need to deploy Enterprise TLS Certificates signed by CA (Instead the self-signed certificates).
The use of Certificates signed by CA is a Security requirement for 'Production' environement.
The customer has created a pull request on the github repo, he developed the solution and tested it - It work fine for him.
The customer need to have this PR integrated in the IBM package to be maintained in the future releases.
The Pull request: https://github.com/WorkloadAutomation/ibm-workload-automation-chart/pull/66
 

Problem:
OpenShift Routes configured with termination: reencrypt require spec.tls.destinationCACertificate so the router can validate the backend TLS certificate. Without it, the HAProxy router cannot verify the pod certificate and returns HTTP 503 for all traffic.

The Helm chart already generates a CA keypair at install time (ca-key-pair Secret) and uses it to sign backend TLS certificates. The destinationCACertificate field should therefore be populated from this same CA so reencrypt works end-to-end.

This is especially relevant when traffic comes through an external load balancer with an enterprise-signed certificate: the LB terminates the enterprise certificate, OpenShift re-encrypts to the pod using the chart-generated CA, and that second hop fails without destinationCACertificate.

Solution:
Conditionally inject destinationCACertificate in route templates when global.routeType is reencrypt, sourcing it at render time via Helm lookup from ca-key-pair (tls.crt).

Impact:

• No duplication needed in values.yaml
• CA rotation is automatically picked up on next helm upgrade
• No behavior change for passthrough or edge routes

Testing:
Validated with helm upgrade --install on OpenShift using global.routeType: reencrypt. Routes are admitted and backend TLS validation succeeds.

Compatibility:
Requires ca-key-pair Secret in namespace (already created by existing chart install logic).

For offline helm template rendering (no live cluster), lookup does not resolve and destinationCACertificate is omitted; this is expected Helm behavior.