Connection configuration for external and subchart backend services (postgreqsl, opensearch, s3, etc)

[jaolwi]

The configuration of connection for each backend service should be available under invenio. and not in the root of values.yaml. We can use functions to dynamically assemble the connection strings and also connect external databases, etc. With enable: false-like parameter we could then ignore individual backend services. Or if the subchart of the backend service is in use, the chart ignores this section completly.

Example:

invenio:
  rabbitmq:
      ## @param invenio.rabbitmq.host Rabbitmq hostname. Only used when `global.rabbitmqEnabled` is false.
      ##
      host: ""
      ## @param invenio.rabbitmq.port Rabbitmq port. Only used when `global.rabbitmqEnabled` is false.
      ##
      port: ""
      ## @param invenio.rabbitmq.username Rabbitmq username. Only used when `global.rabbitmqEnabled` is false.
      ##
      username: ""
      ## @param invenio.rabbitmq.password Rabbitmq password. Only used when `global.rabbitmqEnabled` is false.
      ##
      password: ""
      ## @param invenio.rabbitmq.existingSecret Existing secret name for rabbitmq password. Only used when `global.rabbitmqEnabled` is false.
      ##
      existingSecret: ""
      ## @param invenio.rabbitmq.secretKeys.passwordKey Name of key in existing secret to use for password. Only used when `invenio.rabbitmq.existingSecret` is set and `global.rabbitmqEnabled` is false.
      ##
      secretKeys:
        passwordKey: ""

TLS configuration params could also go there.

[egabancho]

Coming from #136 and a question that @lindhe asked.

A global key might make sense but for a slightly different purpose. I'm not sure if we actually need one right now, though.
I don't think it should replace the invenio one. This is what I believe should be the structure that we should try to go to:

## @section Global parameters
## Global Docker image parameters (inspire by bitnami charts)
global:
   ...

## @section Invenio parameters

image:
  registry: 
  repository:
  ...

## Common invenio app parameters
invenio:
   ...

# One section for each kind
web:
worker:
workerBeat:

I am on the fence about the init/install job. I'd love for it to be configurable, i.e. change the commands it runs.
Probably, it requires its own section (more than just true/false). I'm not sure if it should be inside invenio or at the root level.

WDYT?