feat(extract): prefixed signed&private cookies

[andrzejSulkowski]

closes #3246

Cookie Prefixes Support

Motivation

Cookie prefixes (__Host- and __Secure-) are a web security feature that help protect against cookie manipulation and session fixation attacks. This PR enhances Axum's cookie handling by adding proper support for cookie prefixes across all cookie jar types (CookieJar, SignedCookieJar, and PrivateCookieJar).

Solution

This PR implements:

• Support for cookie prefixes with correct attribute enforcement (e.g., Secure flag, Path=/) using the underlying cookie crate's PrefixedJar
• Consistent prefix handling methods (add_prefixed, get_prefixed, remove_prefixed) for all cookie jar types
  Integration of prefix support with signed and private cookies, ensuring the encryption/signing is maintained
• Extended cookie tests to verify cookie encryption/signing rather than plain-text value matching

[Turbo87]

@jplatte do you know if there is a reason why the inner jars are not exposed as public API? seems like that would simplify the implementation quite a bit 🤔

[yanns]

The code is looking good to me.
Nitpick: I don't know if we want some println in the code through.

I don't know enough the API + our consensus about exposing the cookie API to make a decision here.

[andrzejSulkowski]

@jplatte do you know if there is a reason why the inner jars are not exposed as public API? seems like that would simplify the implementation quite a bit 🤔

Are you suggesting we expose the inner jars alongside the current convenience methods, or replace the current API entirely with direct access to the underlying cookie crate jars?

[Turbo87]

Are you suggesting we expose the inner jars alongside the current convenience methods

maybe :D

I don't know the history of this extractor, so before I can form an opinion it would be better to know why this wasn't done in the first place 😅

[andrzejSulkowski]

Are you suggesting we expose the inner jars alongside the current convenience methods

maybe :D

I don't know the history of this extractor, so before I can form an opinion it would be better to know why this wasn't done in the first place 😅

I don't know the historical reasoning either, and I'm not really proficient enough to predict what users might need.
But the hybrid approach seems like a good middle ground - keep the convenience methods for quick development while exposing the inner jars for more tailored use-cases that need the full flexibility of the cookie crate.

What do you think?

[jplatte]

I think the historical reason was that the cookie stuff used to be in axum and David didn't want the cookie crate as part of the public API, to be able to upgrade it across major versions within a minor version of axum.

However now the cookie crate is already part of the public API anyways, so I think we might as well.. Maybe?

It's been a while that I've actually looked at the details here. If you want, I can take a closer look before time is spent on refactoring stuff here that may be reversed again at some point.