Expose X-Forwarded-For listener parameters

What does this MR do?

Adds a config.xForwardedFor block that exposes the OpenBao TCP listener x_forwarded_for_* parameters. With it, OpenBao can record the original client address in audit logs instead of the address of the ingress controller.

Value	Default	Rendered as
authorizedAddrs	[]	x_forwarded_for_authorized_addrs (comma-separated string)
hopSkips	0	x_forwarded_for_hop_skips (integer)
rejectNotPresent	false	x_forwarded_for_reject_not_present (boolean)
rejectNotAuthorized	false	x_forwarded_for_reject_not_authorized (boolean)

• The parameters are only rendered when authorizedAddrs is not empty, so existing deployments see no change on upgrade.
• They are only set on the API listener. The metrics listener does not get them.
• The defaults match what OpenBao does in code. The OpenBao docs list "true" as the default for both reject flags, but in the code they default to false. Setting authorizedAddrs alone therefore changes nothing else.
• rejectNotPresent must stay false with the default probes, because kubelet probes call /v1/sys/health without an X-Forwarded-For header.
• authorizedAddrs only accepts a list. An empty string makes OpenBao fail to start.
• hopSkips and the booleans are rendered as native JSON types, because OpenBao parses them with ParseInt/ParseBool.
• x_forwarded_for_client_cert_* parameters are out of scope.
• Chart version bumped to 0.20.0.
• values.schema.json was edited by hand to match the helm-values-schema-json output, because the generator was not available locally. The check-values-schema job checks that it matches.
• The schema does not restrict authorizedAddrs entries to strings. The generator rejects the # @schema items:{"type":"string"} annotation (unknown annotation "items"), so it was dropped and authorizedAddrs is only typed as array.

User-facing docs and the subchart bump will follow in gitlab-org/charts/gitlab.

Author's Checklist

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• Ensure a release milestone is set.
• MR title and description are up to date, accurate, and descriptive.
• MR targeting the appropriate branch.
• MR has a green pipeline on GitLab.com.
• When ready for review, MR is labeled workflowready for review per the MR workflow.

Expected

• Test plan indicating conditions for success has been posted and passes.
• Documentation is created or updated. Follow-up in gitlab-org/charts/gitlab.
• Tests are added.

Related issues

Relates to gitlab-org/gitlab#583371