When passing Python's NoneType down to Werkzeug, it uses this logic:

if samesite is not None:
    samesite = samesite.title()

    if samesite not in {"Strict", "Lax", "None"}:
        raise ValueError("SameSite must be 'Strict', 'Lax', or 'None'.")

This means that when OctoPrint converted any strings 'None' into NoneType,
they would not show up in the Set-Cookie header.

Investigation: https://community.octoprint.org/t/unable-to-log-into-octoprint-through-an-iframe-on-home-assistant/33977/20?u=charlie_powell

Link to werkzeug source: https://github.com/pallets/werkzeug/blob/1dde4b1790f9c46b7122bb8225e6b48a5b22a615/src/werkzeug/http.py#L1213-L1217

Docs, while not explicitly clear, here: https://werkzeug.palletsprojects.com/en/1.0.x/http/?highlight=dump_cookie#werkzeug.http.dump_cookie

What does this PR do and why is it necessary?

Adjusts the cookie-setting behaviour so that setting SameSite=None is possible.

How was it tested? How can it be tested by the reviewer?

Analysing the headers in the responses, to ensure this was visible.

The unit tests had to be adjusted, since they were testing the function worked as expected but not far enough into what the end result was.

Any background context you want to provide?

See links above, but also https://web.dev/samesite-cookies-explained/ which helped me to understand what I was looking for here.

What are the relevant tickets if any?

See forum link

Screenshots (if appropriate)

None

Further notes

I think I got this one right, but it needs a good look to double check that my logic is OK. I was never able to get the SameSite=None to show up in Set-Cookie without this change, now it should work OK.