Issue Description: 

Currently we rely on the envFrom directive to configure the Deployment of the Shard e.g:

 envFrom:
  - configMapRef:
      name: event-bridge-shard-operator-config
  - secretRef:
      name: event-bridge-shard-operator-secrets

This poses a particular challenge in the AddOn model of deployment in that if the Configuration is changed, the Shard does not reload. We also see this in our own dev/stable environments with MGDOBR-229.

Instead, the Shard could read it's configuration from a well-known location on start-up and then setup a Watch on the configuration. If the configuration is changed at any point, the Shard could simply "reload" the configuration.

This is the exact pattern followed in RHOSAK, see the following examples:

• https://github.com/bf2fc6cc711aee1a0c2a/kas-fleetshard/blob/5859d9a982f7dbcd8142c5aac8931e965606efec/sync/src/main/resources/application.properties#L46-L47
• https://github.com/bf2fc6cc711aee1a0c2a/kas-fleetshard/blob/5859d9a982f7dbcd8142c5aac8931e965606efec/sync/src/main/java/org/bf2/sync/informer/SecretRestartHandler.java

Acceptance Criteria: 

• Use the https://quarkus.io/guides/kubernetes-config extension to have the Shard read a well-defined secret on start-up for it's configuration
• Create the ability for the Shard to "reload" it's configuration if it is changed
• Remove the envFrom directive from our kustomize configuration for the Shard.