Background
Currently, there are multiple ConfigMaps with user-provided data that are watched by the operator for updates. Including CA bundle ConfigMaps and run.yaml data ConfigMaps.

This can potentially create unnecessary resource overhead on very busy Kubernetes clusters that have many ConfigMaps. Especially if they're older clusters that do not have field indexer support.

Proposed solution

• Add an arbitrary data field for run.yaml data (e.g. spec.server.userConfig.customConfig), to be used similar to the way ConfigMaps are currently used for this purpose. This should be independent of Proposal: Add run.yaml directly into LLSD as a sub-schema #117 so it can be used for custom distributions, etc. Where we don't enforce the schema.
• Add a field for PEM formatted custom CA bundle data (e.g. spec.server.tlsConfig.caBundle.Data)
• No longer watch CA bundle and run.yaml related ConfigMaps for updates.

Pros

• A LlamaStackDistribution becomes the single source of truth for data that's currently fragmented into 3 pieces (llds, run.yaml, CA bundle).
• Fewer resources to watch for updates, - just the LlamaStackDistribution itself for run.yaml or CA data. (+DSCInitialization midstream later)
• Less time between the time-of-check and the time-of-use for PEM data.

Cons

• Indirection / another layer of abstraction: the relevant data from LlamaStackDistribution will likely need to be turned into an ephemeral ConfigMap in order to be mounted by the pod.
• The midstream implementation may end up with some duplicate ConfigMap data, if copied directly from the DSCInitialization into an operator-managed ephemeral ConfigMap.