Auth adds Set-Cookie headers to every response

Hi to all!

It seems to me that any protected endpoint [will add both the XSRF protection and Session cookies to the response](https://github.com/haskell-servant/servant/blob/bd9e4b10900d04bb5a24bcbb8ab2f7246fcd15c7/servant-auth/servant-auth-server/README.lhs#L174-L193). Is there a reason why this is necessary?

I ask that because at our shop we have an end-to-end test failing in an endpoint that changes the auth cookie of a logged in user, a failure caused due to the response containing two `Set-Cookie: JWT-Cookie=...` headers. Apparently it is not deterministic which cookie the browser should pick, so this doesn't always work as intended. Note that this might be hard to replicate in most use cases; With Chromium, we've seen it happen very often only when two requests hit the endpoint within the same second.

But even in a less contrived scenario, I think this could make [clearSession](https://hackage.haskell.org/package/servant-auth-server-0.4.7.0/docs/Servant-Auth-Server.html#v:clearSession) fallible. [RFC 6265](https://datatracker.ietf.org/doc/html/rfc6265#section-4.2.2) says

_" Although cookies are serialized linearly in the Cookie header,
servers SHOULD NOT rely upon the serialization order. In particular,
if the Cookie header contains two cookies with the same name (e.g.,
that were set with different Path or Domain attributes), servers
SHOULD NOT rely upon the order in which these cookies appear in the
header."_

It seems to me the spec above refers to how **servers** handle cookies, and I couldn't find anything clearly specifying client behaviour, but I guess it might be better avoiding two cookies with the same name in the response nonetheless?

IIUC this could all be addressed by removing Set-Cookie headers from _every_ response, adding them only in `acceptLogin`, `clearSession` and similar functions.

Please let me know if you want more details or if I'm just getting things wrong, and thanks!

Start with the linked servant-auth-server README.lhs section and the Servant-Auth-Server documentation for acceptLogin and clearSession. Reproduce a protected endpoint response that contains duplicate Set-Cookie headers, including concurrent requests, then inspect the related authentication flow. Done means the intended cookie-setting behavior is defined and covered for login, session clearing, and protected responses.

Written by the indexing model from the issue text.