feat: Feast Namespaces registry for client ConfigMaps availability

[jyejare]

What this PR does / why we need it:

The Feast Namespace Registry is a feature that automatically creates and maintains a centralized ConfigMap containing information about all Feast feature store instances deployed by the operator. This enables dashboard applications and other tools to discover and connect to Feast instances across different namespaces. This addresses:

1. ConfigMap Creation: The operator creates a ConfigMap in the appropriate namespace:

   • OpenShift AI: redhat-ods-applications namespace (or DSCi configured namespace)
   • Kubernetes: feast-operator-system namespace

2. Access Control: A RoleBinding is created to allow system:authenticated users to read the ConfigMap

3. Automatic Registration and removal: When a new feature store instance is created, it automatically registers its namespace and client configuration in the ConfigMap. Also when feature store is removed it automatically removes the entry from registry.

4. Data Structure: The ConfigMap contains a JSON structure with namespace names as keys and lists of client configuration names as values

{
  "namespaces": {
    "namespace-1": ["client-config-1", "client-config-2"],
    "namespace-2": ["client-config-3"]
  }
}

Usage

The namespace registry is automatically deployed/updated when any Feast feature store instance is created. No additional configuration is required.

ODH Flow Usage:

Which issue(s) this PR fixes:

This implementation addresses the following requirements from RHOAIENG-33698

Misc

[ntkathole]

@jyejare Please fix the formatting and rebase

[jyejare]

@ntkathole Done.

[ntkathole]

Looks good! For future enhancement, it would be great if we can make it configurable and allow to define namespace explicitly in CR instance.