fix/webauthn-abort-controller-race-condition

[MasterKale]

This PR attempts to remove a race condition from browser's WebAuthnAbortService. It was discovered that multiple invocations of startAuthentication() in a row (especially in a SPA using clientside routing), particularly when conditional UI is started, could lead to WebAuthnAbortService.reset() being called early which would fail a subsequent call to startAuthentication() with a DOMException and "a request is already pending."

I determined that this was due to the call to this.controller.abort() not actually aborting the navigator.credentials.get() synchronously. We can't await an AbortController.abort() to wait for the navigator.credentials.get() to be aborted; we can only abort and cross our fingers that we don't call startAuthentication() until the WebAuthn API call actually terminates in response to the abort signal.

This can lead to .reset() being called by the first startAuthentication()'s try / catch / finally after a subsequent call to webauthnAbortService.createNewAbortSignal(), which expects this.controller to be populated with the new controller but ends up becoming undefined when the .reset() gets called after the first controller calls .abort(). The second call to startAuthentication() can no longer be aborted, and a third call will error out because the second WebAuthn API call is indeed still pending.

See #273 (comment), I included some logging output that might make it clearer if the above description is insufficient.

The fix is to remove the reset() method from WebAuthnAbortService. In testing I observed no issues with possibly repeatedly calling .abort() on an already-aborted controller. Thus we can leave the service's this.controller populated between calls to createNewAbortSignal() and forget about trying to tame a race condition.

Fixes #273.

Demonstration

Screen.Recording.2022-09-27.at.9.08.30.PM.mov