feat: generate postgres user secret with r2dbc uris

[bullshit]

Checklist:

• [x] Have you added an explanation of what your changes do and why you'd like them to be included?
• [x] Have you updated or added documentation for the change, as applicable?
• [x] Have you tested your changes on all related environments with successful results, as applicable?
  • [x] Have you added automated tests?

Type of Changes:

• [ ] New feature
• [ ] Bug fix
• [ ] Documentation
• [ ] Testing enhancement
• [x] Other

What is the current behavior (link to any open issues here)?

The operator generates user secrets. For example if you use a r2dbc based application you cannot reference the jdbc-uri key from the secret.

What is the new behavior (if this is a feature change)?

• [ ] Breaking change (fix or feature that would cause existing functionality to change)

r2dbc-uri keys are added to the secrets starting with r2dbc:postgresql://....

Other Information:

[bullshit]

Any feedback regarding this PR? Maybe @dsessler7 could approve this change.

[bullshit]

Is there any reason this contribution is stagnates?

[andrewlecuyer]

Hi @bullshit, I was actually just reviewing your changes yesterday. And as we continue to see requests for additional flavors/variants of the connection details within the user Secret (such as additional URI variants, e.g. for r2dbc, in addition to different flavors of the various keys within the Secret, e.g. user vs. username, or db vs. database vs. dbname, etc.), I am currently assessing options that might provide even more flexibility for the many connectivity use-cases/needs we see out in the wild.

So in other words, rather than endlessly polluting the Secret with access keys, URI's, etc. for that many different variants out there, if would be great to provide users with the ability to define (via the PostgresCluster spec) the exact keys, URI's, etc. they need. And right now I have a couple ideas/designs that I would like to think through before adding another yet key to the Secret. E.g. here is a POC for what something like this might looks like:

spec:
  users:
    - name: rhino
      secret:
        credentialMappings:
          user:
          - username
          - uname
          password:
          - pass
          - pwd
          - passwd
          dbname:
          - database
          - databasename
          - db
          host:
          - hostname
          - hostName
          port:
          - pgPort
        customURIs:
        # user has access to "user", "password", "host" & "port" to build/template out
        # any custom URI needed
        - r2dbc: "r2dbc:postgres://$(user):$(password)@$(host):$(port)/$(dbname)

Which as you cam see, would be another way to get you the r2dbc URI you're looking for:

$ kubectl get secret -n postgres-operator hippo-pguser-someone -o yaml
apiVersion: v1
data:
...
  r2dbc: cjJkYmM6Ly9zb21lb25lOkh2OSUzRitfX1d4PWlWSHhSWjY5eVlZM3dWQGhpcHBvLXByaW1hcnkucG9zdGdyZXMtb3BlcmF0b3Iuc3ZjOjU0MzIvc29tZW9uZQ==
...

I welcome any thoughts/feedback.