[xray] Allow setting extra SecurityContext settings

[mrarends]

PR Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• Chart Version bumped
• CHANGELOG.md updated
• Variables and other changes are documented in the README.md
• Title of the PR starts with chart name (e.g. [artifactory])

What this PR does / why we need it:
This PR adds an extraSecurityContext option to the Xray pod to allow users to disable IPv6 inside the pod. This is useful for clusters that do not support IPv6 or have issues with it. For example, on our Rancher cluster, we encountered errors like:

2023-05-10T11:31:17.929566755Z [jfxr ] [WARN ] [39110377c4799179] [asm_amd64.s:1594 ] [main ] (--wrapper--)Failed fetch entitlements rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp [::1]:8046: connect: connection refused"

This was caused by the Xray router container listening on 127.0.0.1:8046 but the other containers like xray-server trying to connect to the router on [::1]:8046.

To disable IPv6, we need to set the following sysctl parameter using the securityContext:

  # Disable ipv6 inside the pod
  sysctls:
    - name: net.ipv6.conf.all.disable_ipv6
      value: "1"

The extraSecurityContext option allows us to pass this parameter and any other security-related settings to the pod.

(see also support case #250531)

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #

Special notes for your reviewer:

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[mrarends]

I have read the CLA Document and I hereby sign the CLA

[mrarends]

However, I continue to believe that this is a bug in Xray. If one container is utilising IPv6, then all containers should uniformly use IPv6 throughout, rather than having some spots using IPv4 while others use IPv6.

[Logeshwarsn]

@mrarends Thanks for the PR . We would like to evaluate internally and see if we can provide a better solution. We will take this as an enhancement.

[megha1906]

@mrarends thanks for the PR. We have added securityContext and containerSecurityContext at the root level. This approach better aligns with our overall design and security requirements. Therefore, we won't be able to merge your changes at this time. We appreciate your contribution and encourage you to continue sharing your ideas and improvements with us.
cc @rahulsadanandan