Goal Summary
Allow the RHACS Central Custom Resource (CR) to define global NodeSelectors and tolerations that are automatically inherited by all resources managed by Central. This enhancement reduces repetitive configuration, simplifies scheduling control, and aligns Central CR behavior with common Kubernetes workload management practices.

Goals and Expected User Outcomes
 * Primary Persona: Cluster Administrators and Platform Engineers

 * Administrators can define NodeSelectors and tolerations once in the Central CR spec

 * All Central-managed subresources (e.g., deployments, pods) automatically inherit these scheduling constraints

 * Simplifies management by avoiding duplication of NodeSelectors/tolerations across multiple resource definitions

 * Expands the Central CR feature set to provide consistent scheduling policies for RHACS workloads

Acceptance Criteria
 * Central CR spec supports global NodeSelectors and tolerations fields

 * All subresources created or managed by Central inherit these NodeSelectors/tolerations by default

 * Administrators retain the ability to override scheduling settings at individual resource levels if needed

 * No regression in Central availability, upgrades, or operator reconciliation logic

 * Non-functional requirements:

 ** Security: No weakening of security posture due to scheduling changes

 ** Reliability: Central and subresources schedule correctly and consistently across supported platforms

 ** Performance: No negative impact on startup or reconciliation time

 ** Maintainability: Configuration is centralized in CR and documented clearly

 ** Scalability: Behavior remains consistent in large-scale or multi-node environments

 ** Usability: Administrators can confirm applied NodeSelectors/tolerations using oc describe or similar commands

Success Criteria or KPIs Measured
 * Adoption metric: % of deployments using global NodeSelectors/tolerations through Central CR

 * User experience metric: Reduction in configuration errors or support cases caused by missing tolerations/NodeSelectors

 * Operational metric: Time saved by avoiding repetitive manual scheduling configuration across subresources

Use Cases (Optional)
 # Central CR defines a NodeSelector to pin RHACS workloads to infrastructure nodes; all managed pods inherit this configuration automatically

 # Central CR defines tolerations to allow scheduling on tainted nodes for RHACS components; subresources schedule without requiring per-resource edits

 # An administrator validates consistency by checking that all Central-managed pods share the same NodeSelectors/tolerations applied in the CR

Out of Scope (Optional)
 * Changing default scheduling logic for other RHACS components not managed by Central CR

 * Providing advanced scheduling policies beyond NodeSelectors and tolerations (e.g., affinity, anti-affinity, topology spread)

 * Dynamic runtime modification of scheduling beyond what is supported in standard CR reconciliation