fix: add support for storage key

[J0]

What kind of change does this PR introduce?

Address #19 to allow developer to configure storageKey when using createBrowserClient() client side. Not relevant for server-side as cookies are used there.

[hf]

Wait why not createServerClient? These values must be synced up, otherwise wrong cookies will be read.

[J0]

Initial consideration was that on server side they'd be able to set it via: options?.cookieOptions?.name - was under impression from description that we primarily to want to allow the option of setting storageKey via options?.cookieOptions?.name on browser

It seems fine to allow this on createServerClient as well though. Pushed up to support on createServerClient as well

[J0]

Hey @hf @j4w8n,

Rounding out old PRs here - could I trouble y'all for a review when free? Happy to close too if this is not something we wish to pursue

[j4w8n]

I just tested things as they are, in v0.5.1, and had no issues setting the cookie name via { auth: { storageKey: 'thing' } }. The ...auth?.options lines take care of this behavior. Has anyone been able to reproduce the issue? It tried to see if things changed with another PR, but didn't find anything.

No matter what, we should consider changing the order of things though. For instance, ...auth?.options is before ...(options?.cookieOptions?.name in the browser client, but they're reversed in the server client. Which means if someone happened to set both, and the values were different, then they'd get inconsistent results. I doubt someone would do those things, but it might benefit us to align the order.

[j4w8n]

Actually, perhaps as a side effect, @hf looks to have resolved the user's issue with the v0.4.0 rewrite. Y'all can double-check, but I think we can close this PR. My tiny concern with the order of things might want to be addressed though.

@J0

[J0]

Sounds good, thanks for the input! Note that we should look into the ordering.