Description of problem:

The current implementation of the Operator uses a hardcoded definition of the resources to connect to the database. This configuration is defined in the sonataflow.yaml file. Basically the configuration follows the same pattern for the database managed by the operator when the `enableLocalDb` property is enabled.

If you want to use a different database, including different resource names to manage the service and secret, it is not possible. The Operator will always recreate those objects automatically in each deploy. Here a screenshot of that behavior after a rollout:

The `CreateContainerConfigError` is becase the same event:

Error: secret "backstage-psql-secret-developer-hub" not found 

If you create your own `SonataFlowPlatform` object using your own configuration, and declare the Orchestrator Plugins with the new data service, it is working as expected. However, the Operator recreates always the other objects producing the behavior of different pods failing for wrong configuration.

Prerequisites (if any, like setup, operators/versions):

Steps to Reproduce

Here there is an example of recreation of a full Red Hat Developer Hub instance using an external database with the steps to reproduce the behavior described here: https://github.com/rmarting/rhdh-exercises/blob/main/README-ee-database.md

Actual results:

Multiple pods of the `SonataFlowPlatform` CR created with errors.

Expected results:

Reuse SonataFlowPlatform objects created by the user with the right configuration, or allow to recreate the same objects managed by the Operator setting up the resource names wanted.

Reproducibility (Always/Intermittent/Only Once): Always

Build Details:

Additional info (Such as Logs, Screenshots, etc):