[bitnami/rabbitmq] remove undefined rts key from network policy template

[JustinHallquist]

Description of the change

Removes a undefined rts key from networkpolicy.yaml

Currently, modifying the .Values.extraEgress fails chart rendering as the template is looking for an rts key, which is neither specified in the documentation of the .Values nor present anywhere else in the chart for reference points as to how to use it.

The error produced when .Values.extraEgress is defined:

Helm upgrade failed: template: rabbitmq/templates/networkpolicy.yaml:47:64: executing "rabbitmq/templates/networkpolicy.yaml" at <.Values.rts.networkPolicy.extraEgress>: nil pointer evaluating interface {}.networkPolicy

The work around is to define both .Values.extraEgress and .Values.rts.extraEgress to pass the initial feature flag and enable the block render

By removing the undefined rts key, the workaround is no longer necessary and the template matches the .Values.extraEgress documentation

Benefits

• .Values.extraEgress expected behavior reestablished
• Restores .Values.extraEgress documentation validity
• Matches the extraIngress interface

Possible drawbacks

Nonbackwards compatibility for anyone who added a .Values.rts block to work around the issue

Applicable issues

• fixes #23032

Additional information

Checklist

• Chart version bumped in Chart.yaml according to semver. This is not necessary when the changes only affect README.md files.
• Variables are documented in the values.yaml and added to the README.md using readme-generator-for-helm
• Title of the pull request follows this pattern [bitnami/<name_of_the_chart>] Descriptive title
• All commits signed off and in agreement of Developer Certificate of Origin (DCO)

[JustinHallquist]

Is there a way to see the failed spec for the VIB Verify test?
All I can see is Error: Execution graph succeeded, however some tasks didn't pass the verification. and an execution graph url link I do not have access to view.

Aside from that, it seems unlikely that this change would break the test since the runtime-parameters.yaml does not specify a networkPolicy.extraEgress so it would have been feature flagged off with or without the update.

For some additional digging, I did run the test on two different clusters:

• EKS cluster which passed (I did use a ClusterIP rather than a Load Balancer)
• local k3s cluster which failed 2775 -> 2777 mnensia perms (the rest of the tests passed) so I believe that's more likely due to my storage class provisioner defaults and nothing to do with network policies

Would you happen to have any suggestions for next steps here on my end?

[dgomezleon]

Just a minor change related to the versioning