feat: auto-watch ODH CA bundles for updates

[rhdedgar]

Adds a watch for CA bundle ConfigMaps that are referenced by LlamaStackDistributions.

This will most likely be made obsolete by #134 if we can move away from ConfigMap-provided data, and use the LlamaStackDistribution (+DSCInitialization midstream) for all configuration related to run.yaml and CA bundle data. This should provide a decent holdover until we can reach that state.

[mfleader]

I think we should add these test cases for your changes

• Unit: auto ODH annotation

  • Given: CR without spec.server.tlsConfig.caBundle; namespace has ConfigMap named odh-trusted-ca-bundle with 2 valid PEM keys
  • When: buildPodAnnotations runs
  • Then: pod template has configmap.hash/odh-ca-bundle and does not have configmap.hash/ca-bundle

• Unit: explicit CA takes precedence

  • Given: CR with explicit spec.server.tlsConfig.caBundle; namespace may also have odh-trusted-ca-bundle
  • When: buildPodAnnotations runs
  • Then: pod template has configmap.hash/ca-bundle and does not have configmap.hash/odh-ca-bundle

• Unit: deterministic ODH hash

  • Given: Two ConfigMap objects named odh-trusted-ca-bundle with identical key/value pairs but different key insertion orders
  • When: getAutoDetectedCABundleConfigMapHash runs for each
  • Then: hashes are equal; changing any cert content or the set of keys changes the hash

• Envtest: ODH watch maps to CR and triggers rollout

  • Given: CR without explicit CA; ConfigMap odh-trusted-ca-bundle with valid PEM keys in the same namespace
  • When: findLlamaStackDistributionsForConfigMap is invoked for that ConfigMap, and the CR is reconciled
  • Then: the CR is returned by the mapper; the resulting Deployment template includes configmap.hash/odh-ca-bundle; updating the ConfigMap data results in a different annotation value on the Deployment template