Add support for the SameSite cookie attribute

[ozataman]

Chrome is now producing warnings that cross site requests will be disabled unless marked with SameSite=None in the near future. Dropping into using the cookie package is always an option but a significant inconvenience prone to mistakes.

[mightybyte]

What do you think SameSite support should look like?

[jkachmar]

I think it would probably make sense to copy what the cookie package is doing here:

• create a SameSiteOption sum type representing the different SameSite cookie attributes
• add cookieSameSite :: Maybe SameSiteOption to Snap's Cookie
• chase down and resolve the resulting type errors

---

The difficult question, to me, is what to do about the fact that this is going to be a breaking change. There are a few paths I can think of here, but I like the following two the best:

1. Make the above changes, hide Cookie behind smart constructors (cf. SetCookie, and release this as breaking
2. Create a new cookie record with the SameSite attribute hidden behind smart constructors, use this new record everywhere internally, create a mapping function from the existing Cookie with a default SameSite value of None, mark the existing Cookie as deprecated, and release this as a non-breaking change
   • naming would be an issue here, since Cookie precisely captures what this structure is supposed to be and it would necessarily not be possible to change the name without incurring another breaking change in the future
   • technically deprecation notices are breaking changes, but this is bad policy and there's been an open issue to update the PVP with respect to this for years (cf. Revise deprecation clause haskell/pvp#12)