# Summary

Fixes
mongodb/mongodb-kubernetes-operator#1522.

This is a port of
mongodb/mongodb-kubernetes-operator#1582.

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

This is useful to handle more deployment scenarios, in particular,
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](https://kubernetes.io/docs/concepts/architecture/garbage-collection/#owners-dependents),
cross-namespace owner references are disallowed, thus allowing for the
secrets to be immediately garbage-collected, as stated in
mongodb/mongodb-kubernetes-operator#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](https://github.com/emberstack/kubernetes-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
that allows MongoDB Community Operator users to specify per-user
connection string secret annotations.

## Proof of Work

I've added a unit test and an e2e test. The unit test is passing.
Regarding the e2e test, it was passing in the
mongodb-kubernetes-operator repository, but I couldn't figure out how to
run the e2e tests in this repository.

## Checklist
- [ ] Have you linked a jira ticket and/or is the ticket in the title?
  - No, should I create an issue in this repository for that?
- [ ] Have you checked whether your jira ticket required DOCSP changes?
  - What does this mean?
- [ ] Have you checked for release_note changes?

## Reminder (Please remove this when merging)
- Please try to Approve or Reject Changes the PR, keep PRs in review as
short as possible
- Our Short Guide for PRs:
[Link](https://docs.google.com/document/d/1T93KUtdvONq43vfTfUt8l92uo4e4SEEvFbIEKOxGr44/edit?tab=t.0)
  - I can't access this link
- Remember the following Communication Standards - use comment prefixes
for clarity:
  * **blocking**: Must be addressed before approval.
  * **follow-up**: Can be addressed in a later PR or ticket.
  * **q**: Clarifying question.
  * **nit**: Non-blocking suggestions.
  * **note**: Side-note, non-actionable. Example: Praise 
  * --> no prefix is considered a question