feat(gateway-api): allow header-based sticky session (ConsistentHash.Header)

[HR-Gabriel-Cornesse]

Summary

Adds a new service advanced setting network.gateway_api.sticky_session_header that switches the generated BackendTrafficPolicy.loadBalancer.consistentHash from Cookie to Header when set.

The existing cookie-based affinity (INGRESSCOOKIE_QOVERY) is the default and remains unchanged when the setting is unset (null) — fully backward compatible.

Motivation

Cookie-based affinity is unusable for clients that cannot persist HTTP cookies:

• MCP servers (Model Context Protocol — the emerging standard for LLM tool integration) key sessions off the Mcp-Session-Id header per spec.
• MCP clients (n8n, Claude Desktop, Claude Code, MCP Inspector, Cursor, Google ADK, OpenAI Agents SDK, etc.) use raw fetch() / undici without cookie jar support, so Set-Cookie from the ingress is simply dropped.
• Without header-based affinity, stateful MCP servers cannot scale past one replica behind Qovery's gateway — every POST gets randomly routed and the client ends up re-initializing in a loop.

The same applies to any HTTP client that uses bearer-token auth + a custom session header (common in gRPC + metadata, or internal microservices).

Changes

• Add network_gateway_api_sticky_session_header: Option<String> to ApplicationAdvancedSettings, ContainerAdvancedSettings, and HelmChartAdvancedSettings with serde alias network.gateway_api.sticky_session_header.
• Propagate the new field in ApplicationAdvancedSettings::to_container_advanced_settings.
• Update the HTTPRoute and GRPCRoute BackendTrafficPolicy Jinja templates to emit ConsistentHash.Header when the setting is non-empty, keep the existing Cookie branch otherwise.
• Update the four tests/helm/mod.rs struct literals to include the new field (defaults to None, no behavior change).

Backward compatibility

Zero behavior change for existing users: the setting defaults to None, which preserves the current INGRESSCOOKIE_QOVERY cookie-based ConsistentHash.

Test plan

• cargo check passes (verified locally — 2m04s).
• cargo check --tests passes (verified locally — 1m18s, all tests/helm/mod.rs struct literals compile).
• Manual: templates render identically when setting is absent/None (cookie branch unchanged — should diff-clean vs engine-public).
• Manual: templates render header-based ConsistentHash when setting contains a header name.
• End-to-end: deploy a service with network.gateway_api.sticky_session_header = "Mcp-Session-Id" on a 3-replica backend, verify successive requests with the same header value hit the same pod.

[benjaminch]

Hi @HR-Gabriel-Cornesse

Thanks for this contribution, it makes total sense and we would love to integrate this.

I made couple comments on the PR.
Also, please update / add tests for those new use cases, we have one per cloud provider for example: deploy_application_with_sticky_session_enabled_on_aws_eks for EKS source, we have the same for GKE, Scaleway and Azure.

Some changes, especially the enum one can be a bit tricky, let me know if you have time to work on it, otherwise, I can do it.

Cheers

[benjaminch]

suggestion: remove this file

[benjaminch]

suggestion: since this can be now either Cookie or Header, let's push a little bit further and allow the last type SourceIP doc

Hence, let's introduce an enum here:

You can put it here for the time being and import it in the other files

pub enum StickyHeaderType {
  Cookie,
  Header { name: String },
  SourceIp,
}

Then, templates need to be updated as well

[benjaminch]

suggestion: remove this file

[benjaminch]

suggestion: remove this file

[benjaminch]

suggestion: remove this file