[BUG] mongodb-community-operator: changing connectionStringSecretName causes resource leak

[taham0]

What did you do to encounter the bug?
I changed the connectionStringSecretName for the same user which created a new connectionStringSecret for the same password. The old connectionsStringSecret is not deleted.

Steps to reproduce the behavior:

1. Apply the following configuration to create a user with connectionStringSecret named con-str-1:

spec:
  members: 3
  type: ReplicaSet
  users:
  - db: admin
    name: my-user
    passwordSecretRef:
      name: my-user-password
    roles:
    - db: admin
      name: clusterAdmin
    - db: admin
      name: userAdminAnyDatabase
    connectionStringSecretName: con-str-1
  version: 4.4.0

2. Change the connectionStringSecret to anything else:

connectionsStringSecret: new-name

What did you expect?
The operator should delete the old connectionStringSecret for the user if a new secret is created.

What happened instead?
The operator creates a new secret with a new name but the old secret is not deleted.

Operator Information

• Operator Version - 0.7.4
• MongoDB Image used - 4.4.0

Kubernetes Cluster Information

kubectl version --short --output=yaml

$ kubectl version --short --output=yaml
clientVersion:
  buildDate: "2022-05-24T12:26:19Z"
  compiler: gc
  gitCommit: 3ddd0f45aa91e2f30c70734b175631bec5b5825a
  gitTreeState: clean
  gitVersion: v1.24.1
  goVersion: go1.18.2
  major: "1"
  minor: "24"
  platform: linux/amd64
kustomizeVersion: v4.5.4
serverVersion:
  buildDate: "2021-05-21T23:01:33Z"
  compiler: gc
  gitCommit: 5e58841cce77d4bc13713ad2b91fa0d961e69192
  gitTreeState: clean
  gitVersion: v1.21.1
  goVersion: go1.16.4
  major: "1"
  minor: "21"
  platform: linux/amd64

Additional context

• secrets

It can be observed below that new-name has been created in addition to con-str-1.

$ kubectl get secrets -n mongodb
NAME                          TYPE     DATA   AGE
new-name                      Opaque   4      3s
my-scram-scram-credentials    Opaque   6      9h
my-user-password              Opaque   1      9h
con-str-1                     Opaque   4      8h
test-cluster-agent-password   Opaque   1      8h
test-cluster-config           Opaque   1      8h
test-cluster-keyfile          Opaque   1      8h

Possible root cause and fix

We need some way of identifying a connectionStringSecret by the user it was created for.

A naive solution would be to include some information about the user in the secret metadata so that the operator can delete the old secret if it already exists for a user before creating a new one.