feat: customize connection string secret annotations

[limwa]

Summary:

Closes #1522.

In this PR, I've added the ability to add custom annotations to the generated connection string secrets.

This is useful to handle more deployment scenarios, in particular, the scenarios where the operator is not deployed cluster-wide, but to a specific namespace. In these scenarios the connectionStringSecretNamespace property becomes useless, because, as stated in the Kubernetes docs, cross-namespace owner references are disallowed, thus allowing for the secrets to be immediately garbage-collected, as stated in #1578. For the owner references to be valid, the secrets need to be generated in the namespace of the MDBC resource. However, if the user needs the secrets to be present in other namespaces, they can use reflector, for instance, which allows for the secrets to be copied to other namespaces. The problem is that reflector and other similar controllers require the source secrets to be annotated with specific properties.

As such, I've implemented a connectionStringSecretAnnotations property which allows mongodb-kubernetes-operator users to specify per-user connection string secret annotations.

I've done it in this way because I'm not very experienced with Go and this felt like the simplest way to do it. I could've also refactored all of the connection string secret to be grouped under a connectionStringSecret object, but this would break backwards compatibility.

All Submissions:

• Have you opened an Issue before filing this PR?
• Have you signed our CLA?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Put closes #XXXX in your comment to auto-close the issue that your PR fixes (if such).

[mircea-cosbuc]

Thank you for your contribution @limwa , enabling the tests for this and will review to get it to a merge-able state.

[limwa]

Hey @mircea-cosbuc! Is there any thing I need to do or should I just wait? Thanks!

[nammn]

Hey @limwa thanks for the contribution!
Can you add a unit test and update one of our existing e2e tests (example) as well?

Thank you!

[limwa]

Hi. Yes, I'll add the tests (and thank you for the example)! Right now, I'm a bit busy, but I'll pick this up as soon as possible.

[jorgecuesta]

Hi thanks @limwa for this PR, was exaclty what I need and btw, it works smooth.

I build and push to a public registry an image non official from this PR code. I want to let you all know in case someone else came to this before mongodb guys and the pr owner figure out the remaining requirements.

Docker Image: https://hub.docker.com/layers/poktscan/mongodb-kubernetes-operator/pr-1582/images/sha256-be92755482fafd207b1a8ef2f0e48eb9f6cbc58355c3e07bc31c4c9e06780cc4?context=repo

[limwa]

Hey @nammn, regarding the tests, I've added a test that tests for the presence of the annotations in the generated secret.
Also, when testing, I noticed that there was some new code that was autogenerated. I committed it in 0d6e1f2. Please let me know if this is okay and is expected!

If there's anything else I can help with, please let me know! Thank you for your time.

[github-actions]

This PR is being marked stale because it has been open for 60 days with no activity. Please update the PR or ask for a fresh review.

[limwa]

@mircea-cosbuc @lsierant @slaskawi @nammn @Julien-Ben @MaciejKaras @lucian-tosa @fealebenpae can this PR get a review please? Sorry for the notification, but the stale-bot said I should ask for a fresh review