Enable external dismissal

[tristan-warner-smith]

Feature

Enables external control over the view container in order to enable external dismissal and control of the container. With this approach, a client can give the Magic SDK a ViewController in which to nest itself.

### Scope

• Enables clients to provide the container in which the WebViewController is added
• Enables external dismissal of the login flow
• NOTE: Swaps from simply moving the WebViewController to the back (keeping it in the view hierarchy forever) to removing it from the view hierarchy entirely. I'm not sure if there are any other scenarios where this change can be problematic, so you might want to manage this differently.

In our case we have a SwiftUI app so in order to drive this we need to create a view container, but we need to be able to control the display more directly and dismiss the popup according to our logic.

Tradeoffs

• Adds calculated webViewPresenter: WebViewControllerPresenting called from AuthModule.cancelLogin , rather than encapsulating all the APIs called on WebViewController and re-exposing the WebViewController by protocols instead
• Couldn't think of a better name for AuthModule.cancelLogin
• Added code should pass SwiftLint rules but the default SwiftLint rules raise too many issues against the current code so I didn't want to enlarge the scope and address those too.
• Ran out of time to test many scenarios so the default seems to work fine but there's a chance that WebViewController would need to change its constraint code when presented in different containers.

[Ariflo]

NOTE: Swaps from simply moving the WebViewController to the back (keeping it in the view hierarchy forever) to removing it from the view hierarchy entirely. I'm not sure if there are any other scenarios where this change can be problematic, so you might want to manage this differently.

@tristan-warner-smith The WebViewController remaining in the view hierarchy is done so by design. We mainly cater to web3 based apps who utilize our SDK to permit their users to accomplish sensitive actions like transacting with crypto currencies and signing cryptographic messages. As such, the web view must remain in the view hierarchy to keep said users authenticated for such actions.

[Ariflo]

Overall this makes sense, however, we need to consider those developers that do not pass a viewHostProvider and require that the WebView remain in the hierarchy. LMK if you have any thoughts here, otherwise, we can see about taking what you have here and giving developers like yourself some kind of AuthOnly view provider option.

[tristan-warner-smith]

NOTE: Swaps from simply moving the WebViewController to the back (keeping it in the view hierarchy forever) to removing it from the view hierarchy entirely. I'm not sure if there are any other scenarios where this change can be problematic, so you might want to manage this differently.

@tristan-warner-smith The WebViewController remaining in the view hierarchy is done so by design. We mainly cater to web3 based apps who utilize our SDK to permit their users to accomplish sensitive actions like transacting with crypto currencies and signing cryptographic messages. As such, the web view must remain in the view hierarchy to keep said users authenticated for such actions.

Gotcha, yeah not the case for us pure auth users.

I think I've updated the PR with the changes requested, let me know.

[Ariflo]

@tristan-warner-smith apologies for the delays and all the back and forth. Please review our updates on PR #41 and let us know if it will suffice for your purposes here. Thanks!