feat: add optional separate gRPC ingress - #525

What

Adds an optional grpcIngress values block and templates/grpc-ingress.yaml. When enabled, it renders a second Ingress named <fullname>-grpc that routes to the gRPC service port (6334). It is disabled by default and mirrors the existing ingress values: ingressClassName, annotations, additionalLabels, hosts and tls.

Why

REST and gRPC generally can't share one Ingress. For example, ingress-nginx needs nginx.ingress.kubernetes.io/backend-protocol: GRPC on a dedicated Ingress. Until now the chart offered no way to expose gRPC separately.

How was it tested

• helm lint charts/qdrant passes.
• helm template with default values is byte-identical to main.
• With ingress.enabled=true,grpcIngress.enabled=true it renders two Ingresses: qdrant routes to port 6333 and qdrant-grpc routes to port 6334 under the gRPC host, with the configured class, annotations and tls.
• go test ./test passes, including two new render-level tests: disabled by default, and enabled with class, annotations, hosts and tls.
• Not run: the bats integration tests, which need kind and a cluster, and golangci-lint. gofmt is clean.

Notes

• There is no values.schema.json on main. If add values.schema.json for values validation #516 lands first, the new grpcIngress keys will need adding to it.
• Add Gateway API HTTPRoute support #517 adds a top-level httpRoute: block, so the keys don't conflict.
• The nginx backend-protocol: GRPC annotation is left as a commented example in values.yaml, not set by default.

Fixes #402

Authored by Mihir Inamdar.