docs: document sticky sessions via consistentHashKey (#4192)

## Description
Documents that sticky sessions can be achieved using the
`consistentHash` load balancer backend together with
`consistentHashKey`, keyed either by a request header or a path
parameter, as requested in the issue.

cc @szuecs @MustafaSaber, please take a look when you get a chance!

## Changes
* **`docs/reference/filters.md`**:
Added a new subsection, "Sticky sessions by header or by path," right
after the existing `consistentHashKey` section. Includes two example
routes — one pinning by a request header (`My-Header`), one pinning by a
path segment (`:item`) — along with a note on fallback-to-default-key
behavior and a pointer to `consistentHashBalanceFactor`.

## Related Issues
* Closes #4063

Signed-off-by: Shardool Patil <shardoolpatil999@gmail.com>

Author: shardool-patil

docs/reference/filters.md

@@ -3849,11 +3849,45 @@ pr: Path("/products/:productId")
     -> consistentHashKey("${productId}")
     -> <consistentHash, "http://127.0.0.1:9998", "http://127.0.0.1:9997">;
 ```
+
 ```
 consistentHashKey("${request.header.Authorization}")
 consistentHashKey("${request.source}") // same as the default key
 ```
 
+#### Sticky sessions by header or by path
+
+`consistentHashKey` can be used to implement sticky sessions: requests
+that produce the same key are, with high probability, routed to the
+same backend endpoint, without Skipper storing any session state.
+
+To pin requests by a chosen request header, e.g. `My-Header`:
+
+```
+sticky_by_header: *
+    -> consistentHashKey("${request.header.My-Header}")
+    -> <consistentHash, "http://127.0.0.1:9998", "http://127.0.0.1:9997">;
+```
+
+To pin requests by a path segment, e.g. an `:item` id:
+
+```
+sticky_by_path: Path("/items/:item")
+    -> consistentHashKey("${item}")
+    -> <consistentHash, "http://127.0.0.1:9998", "http://127.0.0.1:9997">;
+```
+
+If the chosen header is absent, or the path parameter can't be
+resolved, the filter falls back to the default key
+(`${request.source}`, i.e. the first `X-Forwarded-For` address or the
+client's remote IP) — so make sure the header is always set, or route
+matching guarantees the path parameter is present, if strict pinning
+per header/path value is required.
+
+Use [`consistentHashBalanceFactor`](#consistenthashbalancefactor) to
+prevent a single popular key (a hot product, or many users behind the
+same header/IP) from overloading one backend endpoint.
+
 ### consistentHashBalanceFactor
 
 This filter sets the balance factor used by the [`consistentHash`](backends.md#load-balancer-backend) algorithm to prevent a single backend endpoint from being overloaded.