feat: Add support for OPA authorizer

[sbernauer]

Description

Closes #400

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

# Author
- [x] Changes are OpenShift compatible
- [x] CRD changes approved
- [x] CRD documentation for all fields, following the [style guide](https://docs.stackable.tech/home/nightly/contributor/docs-style-guide).
- [x] Integration tests passed (for non trivial changes)
- [x] Changes need to be "offline" compatible

# Reviewer
- [x] Code contains useful comments
- [x] Code contains useful logging statements
- [x] (Integration-)Test cases added
- [x] Documentation added or updated. Follows the [style guide](https://docs.stackable.tech/home/nightly/contributor/docs-style-guide).
- [x] Changelog updated
- [x] Cargo.toml only contains references to git tags (not specific commits or branches)

# Acceptance
- [ ] Feature Tracker has been updated
- [ ] Proper release label has been added

[NickLarsenNZ]

LGTM

[sbernauer]

In terms of CRD change we have two options:

1. Enable authorizer and group-mapper simultaneous

  # Enable authorizer and group-mapper at the same time
  clusterConfig:
    authorization: # optional
      opa: # mandatory
        configMapName: opa # mandatory
        package: hdfs # mandatory

• Good, because consistent and users can not enable authZ and forget about group mapping
• Good, because rego rules can rely on the groups being propagated (although not recommended)

2. Enable authorizer and group-mapper separately

  clusterConfig:
    authorization: # optional
      opaAuthorization: # mandatory
        configMapName: opa # mandatory
        package: hdfs # mandatory
      opaGroupMapping: # optional
        configMapName: opa # mandatory
        package: hdfs # mandatory

• Good, because more flexible, e.g. you can enable AuthZ without group mapping (which you basically would get for free)
• Bad, because more complex and error-prone

Originally I was thinking of 2., but now I am in favor of 1., as it's simpler and more consistent and 2. only enables stuff we should probably not support :)
User can always use configOverrides to easily partially enabled stuff when they really really want to.

[sbernauer]

Started https://ci.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/hdfs-operator-it-custom/128/

[adwk67]

Just reviewed the docs so far with a few comments. Nit: we use regorule, rego rule and rego-rule here: I don't mind which it is but we should be consistent. The opa docs seem to use two separate words i.e. rego rules.

[sbernauer]

@adwk67 feedback should be addressed

[sbernauer]

Started https://ci.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/hdfs-operator-it-custom/129/

[adwk67]

LGTM! Can merge when the CI tests are all done.

[adwk67]

LGTM! Can merge when the CI tests are all done.

[sbernauer]

And also a full testsuite run: https://ci.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/hdfs-operator-it-custom/130/

[sbernauer]

Another full testsuite run, after I increased the resources in stackabletech/ci@40937a9:
https://ci.stackable.tech/view/02%20Operator%20Tests%20(custom)/job/hdfs-operator-it-custom/131/

[sbernauer]

Full testsuite passed 🚀