Traefik provider: support sticky cookie configuration on generated weighted TraefikService

[nedal87]

Describe the feature

I would like Flagger’s Traefik provider to support configuring sticky cookies on the generated weighted TraefikService (spec.weighted.sticky.cookie).

Problem / Motivation

When running canary analysis for redirect-heavy flows (for example auth/SSO redirects), clients may make multiple HTTP requests that must stay on the same release track (primary or canary) across the sequence. Today, without stickiness on the weighted TraefikService (where the primary/canary split actually happens), the selected branch may change between requests, making these flows harder to validate and potentially causing inconsistent behavior.

Traefik supports sticky sessions on weighted TraefikService via spec.weighted.sticky.cookie.

See:
https://doc.traefik.io/traefik/reference/routing-configuration/kubernetes/crd/http/traefikservice/#sticky-sessions

Proposed solution

Add optional provider-specific configuration for Traefik sticky cookies in the Canary spec, and propagate it into the generated weighted TraefikService.

Desired Canary configuration (proposed):

spec:
  service:
    traefik:
      sticky:
        cookie:
          name: flagger-traefik-sticky
          httpOnly: true
          secure: false
          sameSite: lax
          path: /
          maxAge: 300

Expected generated TraefikService:

spec:
  weighted:
    sticky:
      cookie:
        name: flagger-traefik-sticky
        httpOnly: true
        secure: false
        sameSite: lax
        path: /
        maxAge: 300
    services:
    - name: <primary>
      weight: <...>
    - name: <canary>
      weight: <...>

Backward compatibility

If the sticky cookie config is omitted, behavior remains unchanged (no sticky stanza rendered).

Acceptance criteria

• When sticky cookie config is present in the Canary spec, Flagger generates/updates the TraefikService with spec.weighted.sticky.cookie.* set accordingly.
• When sticky config is absent, the generated TraefikService contains no sticky stanza.
• Unit tests cover both cases (sticky configured / not configured).

Drawbacks / Scope

• Adds Traefik-specific options to Canary configuration.
• This proposal targets WRR-level stickiness for the primary/canary split only (not multi-level/child-service stickiness).

Any alternatives you've considered?

• Rely on app/session handling only: does not guarantee consistent primary/canary branch selection at the Traefik weighted split.
• Implement full multi-level Traefik stickiness immediately: larger scope; starting with WRR-level stickiness is smaller and focused.

Additional context

I am happy to implement and open a PR for this feature.