[Auth] Fix async/await crash from implicitly unwrapped nil error

[ncooke3]

Issue reproducible by changing unit test like so:

---

In the Objective-C implementation, (nil, nil) was being passed back by
getToken during timeouts.

firebase-ios-sdk/FirebaseAuth/Sources/SystemService/FIRAuthAPNSTokenManager.m

Lines 89 to 95 in eca84fd

	dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(_timeout * NSEC_PER_SEC)),
	FIRAuthGlobalWorkQueue(), ^{
	// Only cancel if the pending callbacks remain the same, i.e., not triggered yet.
	if (applicableCallbacks == self->_pendingCallbacks) {
	[self callBackWithToken:nil error:nil];
	}
	});

This didn't cause issue though because the API calling getToken only checked for
the presence of a non-nil token:

firebase-ios-sdk/FirebaseAuth/Sources/AuthProvider/Phone/FIRPhoneAuthProvider.m

Lines 613 to 618 in eca84fd

	[_auth.tokenManager getTokenWithCallback:^(FIRAuthAPNSToken *_Nullable token,
	NSError *_Nullable error) {
	if (!token) {
	[self reCAPTCHAFlowWithUIDelegate:UIDelegate completion:completion];
	return;
	}

In Swift though, the catch block will implicitly unwrap error, leading to the
crash when error is nil due to the timeout:

firebase-ios-sdk/FirebaseAuth/Sources/Swift/AuthProvider/PhoneAuthProvider.swift

Lines 320 to 326 in a5c253d

	var token: AuthAPNSToken
	do {
	token = try await auth.tokenManager.getToken()
	} catch {
	return try await CodeIdentity
	.recaptcha(reCAPTCHAFlowWithUIDelegate(withUIDelegate: uiDelegate))
	}

Since the error doesn't bubble up, how we handle this is an implementation
detail and I think we could either (1) remove the catch block and use try?,
and trigger the catch block's code if the try? await results in nil. Or, (2)
pass an error in the timeout case so a non-nil error is unwrapped. I think (2)
is more future proof so I went with that in this PR.

Fix #13470

[paulb777]

Great fix. Thanks!

[snapxo]

@ncooke3
With this AuthErrorUtils.missingAppTokenError(underlyingError: nil), the user of the SDK has no means to know that the request timed out, apart from implementing a timeout logic on their side, right?

Would it be a solution to add an underlying timeout Error?

[ncooke3]

Hi @snapxo, that's correct that the timeout error doesn't bubble up. This getToken API is called internally and in the case of an error (e.g. like from timeout), it actually attempts the recaptcha flow rather than bubble the error up to the user:

firebase-ios-sdk/FirebaseAuth/Sources/Swift/AuthProvider/PhoneAuthProvider.swift

Lines 321 to 326 in e76d746

	do {
	token = try await auth.tokenManager.getToken()
	} catch {
	return try await CodeIdentity
	.recaptcha(reCAPTCHAFlowWithUIDelegate(withUIDelegate: uiDelegate))
	}

Line 322 may throw the error you've highlighted above.

[snapxo]

Makes sense if the fallback upon every missingToken error is the recaptcha 👌