feat: migrate CA secret to new namespace

[dervoeti]

Description

Fixes #453 by creating a one-time job that copies the secret over to the new namespace if it does not exist there yet.

Definition of Done Checklist

Author

Preview Give feedback

1. Changes are OpenShift compatible
2. Helm chart can be installed and deployed operator works
3. Integration tests passed (for non trivial changes)
4. Changes need to be "offline" compatible

Reviewer

Preview Give feedback

1. Code contains useful comments
2. Code contains useful logging statements
3. (Integration-)Test cases added
4. Documentation added or updated. Follows the style guide.
5. Changelog updated
6. Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

Preview Give feedback

1. Feature Tracker has been updated
2. Proper release label has been added
3. Roadmap has been updated

[NickLarsenNZ]

Approved based on the shellcheck pass, and the described testing (in the team call).

[dervoeti]

I now created separate RBAC rules for the Job now instead of using the ones from secret-operator.

Reasoning (besides better security):
The Job should run before secret-op starts and the SecretClass is created, because otherwise a race condition might occur where secret-op is already started but the Job did not finish yet, hence the Secret is not yet copied over to the new namespace and secret-op might create a new CA (if a Pod requests a cert). Since the Job needs a ServiceAccount to view/edit Secrets and that ServiceAccount needs to be created before the installation of secret-op as well, the ServiceAccount and other RBAC resources have been created and also annotated with the Hook annotations for Helm.
I set the hook-delete-policy to hook-succeeded so all the resources from this one time job will automatically be deleted if it succeeds. The hook-weight annotations make sure the RBAC resources are created before the Job.

Just retested it a couple of times, works as expected.

[labrenbe]

lgtm