feat: introduce experimental split user and session storage

[hf]

A common complaint when using Supabase in SSR is that the cookie size is huge. Some server configurations are not able to use such large cookies.

A major contributor to cookie size is that the user object is stored alongside the access and refresh tokens. This object should not be used on the server but nevertheless has to exist to make this library happy.

This change introduces the ability for this library to store the user object in a separate storage location. For now it's experimental mode to be proofed before being widely adopted.

How does it work?

You can initialize the client by passing in a new option userStorage in addition to the already existing and optional storage option. By default userStorage is not set and a single storage is used for all elements of the session (including user property).

If userStorage is set, all future changes to the session will write the user there, and the rest of the session object to storage.

Unsolvable Problems

Say you set up the client like so:

new GoTrueClient(URL, {
  // ...
  storage: cookieStorage,
  userStorage: window.localStorage,
})

On the server, the cookies -- obviously -- will not contain the user object. Because the Session type defines user: User as non-nullable, attempting to access a property on this object will throw an exception. Instead you should always call getUser() to fetch a trusted and fresh user object. This problem will be solved in v3 of this library.

Testing

This PR can be used to test this PR before merging. Merging should be safe as this is opt-in behavior for now.