feat!: Add new ListenerClass.stickyNodePorts field

[sbernauer]

Description

Part of stackabletech/issues#770
Implementation is in stackabletech/listener-operator#340

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

• Changes are OpenShift compatible
• CRD changes approved
• CRD documentation for all fields, following the style guide.
• Integration tests passed (for non trivial changes)
• Changes need to be "offline" compatible

Reviewer

• Code contains useful comments
• Code contains useful logging statements
• (Integration-)Test cases added
• Documentation added or updated. Follows the style guide.
• Changelog updated
• 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]

What (k8s resources changes) does it result in? Some changes to generated Services or just the generated Listener?

[sbernauer]

What (k8s resources changes) does it result in?

Actually the csi::v1::Volume, which in turn influences the created PVC (I guess). Feel free to have a look at rust/operator-binary/src/csi_server/controller.rs in stackabletech/listener-operator#340

[sbernauer]

Please vote on this comment

[Techassi]

question: Could we somehow detect this and automatically remove the stickiness? Or is that something we don't want?

[sbernauer]

Ideally we have auto-detection in listener-op, which detects what ListenerClasses it should create, based on detecting GKE/AKS/IONOS etc. You might recall this from the CRD maintainer discussions.
But that's a follow-up