[Mobile Payments] Switching store to one which is not set up for TOM leads to a connection loop

[joshheald]

5. I have 2 different Woo accounts. If I use Tap to Pay in a store in one of those accounts, log out, and login to the other account, I can't set up Tap to Pay -- I just get stuck in a loop. I can even get myself into a situation where the cancel button doesn't work and I have to close the app to do anything. (In this video, I'm not tapping anything.)

RPReplay_Final1669922756.MP4

Originally posted by @lmischner in #8273 (comment)

Nice catch! It only seems to happen when the second store isn't set-up for Tap on iPhone, it lets me take a payment if I try and repro it using two stores which I've been through the set-up flow for already.

My first instinct was that we'd need to disconnect the reader when the store changes... but I was surprised that's not already handled for bluetooth readers. It looks like it is handled, as we're not connected to the built-in reader when we go to the set-up flow for the second reader.

I checked what happens when I disconnect the built-in reader in Manage card readers before switching stores, and the issue still shows up then.
– @joshheald

[joshheald]

The reason for this bug is that in the attempts on the second account, we're using an old tokenProvider in the Terminal, so the locationIDs we get are being used against the wrong Stripe account (unconfirmed, but at least with the wrong token.)

We correctly call Terminal.clearCachedCredentials when the store is switched and when the user logs out. That means that the Terminal calls the original tokenProvider (which it still has a reference to) to get a new token when we next connect to a reader.

We can't set a new tokenProvider, because the app crashes with this exception from Stripe:

[StripeTerminal] ⚠️ An integration error was detected in your app. You can only call setTokenProvider before requesting the shared Terminal instance for the first time. We recommend calling setTokenProvider in your AppDelegate's application:didFinishLaunchingWithOptions: method.

To fix it, we'll need to keep a reference to the first token provider we set and update the token that it vends.