[SDK-1473][B2B] Add exchange method to session client

[nidal-stytch]

Linear Ticket: SDK-1473: Add exchange method to session client

Notes:

• The session exchange function works if there is a user that is authenticated by email magic links or oauth and is a member of multiple organizations. You can then call the session exchange function with the id of the org they wish to authenticate with and it will create and return a new member session.

Changes:

1. Extend Sessions to include an exchnage method. And add the ExchangeParameters type.
2. In the b2b sample app remove all usage of a defined property for private let defaults: UserDefaults = .standard and instead refer directly to UserDefaults.standard. I feel that this is confusing and would imply custom usage of user default and not the standard usage.
3. Fix password reset flow in b2b sample app in SceneDelegate, wrong logic was being used to parse out the PasswordsViewController.
4. Remove logic in b2b sample app RootViewController to stop popping to the root view controller every time we got a notification about the session info changing. The RootViewController only ever set the project id and that almost never changes. And with the improved reporting throughout the app, we know when the user needs to be authenticated.

Checklist:

• I have verified that this change works in the relevant demo app, or N/A
• I have added or updated any tests relevant to this change, or N/A
• I have updated any relevant README files for this change, or N/A

[jhaven-stytch]

typo: exchange

[nidal-stytch]

Good catch, just an fyi, I am super dyslexic!

[jhaven-stytch]

Whats with the <B2BAuthenticateResponse>? Is it because it's using the Session client defined in StytchClientCommon? Should we go ahead and break out the session clients into separate ones for B2B and B2C? that way we could do StytchB2BClient.Sessions.ExchangeParameters(), right? Just for consistency with all the other products/methods. I think this current approach might lead to developer confusion.

[nidal-stytch]

I personally feel that it is good the way it is and a good use of swift generics. If I can figure out something with sorcery where I can add a "where" clause to the protocol extensions then we can remove this.

This is the way around this:
public extension Sessions where AuthResponseType == B2BAuthenticateResponse

Then:
Sessions<B2BAuthenticateResponse>.ExchangeParameters
turns into:
Sessions.ExchangeParameters

But currently I can't figure out how to do that with sorcery and I posted a question about how to do that for the generated files here: krzysztofzablocki/Sourcery#1337.

I would only think we need to name space Session if it was to be used in tandem with the B2C session.

[jhaven-stytch]

If we split out the sessions clients (which we do on Android), would that avoid the unknown sourcery stuff? If so, that plus being able to namespace the parameters seems like a win to me. We already have some customer confusion with using two different clients, I just think that this might add to that cognitive load.

[nidal-stytch]

Agreed, after thinking about it and pair programming, I think we do need separate objects for b2b session and b2c session, lets make a ticket to capture this work.