feat: adds cookies.encode option allowing minimal cookie sizes

[hf]

Adds an experimental option encode on the cookies object when using createBrowserClient() and createServerClient().

If this is set to tokens-only then only the user's access token and refresh token will be encoded in the cookies, causing significant cookie size savings, often greater than 50%. It utilizes split session storage in auth-js, with some trade-offs such as the inability to access the user property on the supabase.auth.getSession() object in the server. This wasn't supposed to be done anyway, and getClaims() is a secure alternative for it.

[j4w8n]

Nice.

Have you considered setting the fallback for userStorage to null in each case? Then the encode option would be a great way for developers to just not store user anywhere unless we set userStorage explicitly ourselves. This has the great benefit of avoiding the warnings of supabase/supabase-js#1709, since Supabase source code also calls getSession() for various things that trigger the warning; more secure all around.

[hf]

@j4w8n Null userStorage would break existing semantics in auth-js. I'd rather it gets controlled by a flag like this instead until we figure out how to do this in the next major version properly.

[wong2]

Is it safe to switch from the default behavior to tokens-only for a production app? Like will the currently auth-ed users working normally?