Currently, //content restricts the WebAuthn API to have at most one request at a time in each RenderFrame.

On the one hand, this might be too restrictive for some embedders, while on the other hand, it's not restrictive enough for //chrome, which renders UI on a per-WebContents basis, so cannot handle multiple frames issuing one request each at the same time.

Ultimately, we should get to a state where:

 (1) //content can handle any number of simultaneous WebAuthn requests, 
 (2) the embedder can reject requests however it sees fit,
 (3) the embedder can put requests "on hold" before they start (e.g. the API would return a promise, but the discoveries would not start until the embedder says so)
 (4) the embedder can put suspend requests even after they have already started (e.g. the discoveries and device communication would be suspended, so that another request can be started).
 

Currently, //content restricts the WebAuthn API to have at most one request at a time in each RenderFrame.

On the one hand, this might be too restrictive for some embedders, while on the other hand, it's not restrictive enough for //chrome, which renders UI on a per-WebContents basis, so cannot handle multiple frames issuing one request each at the same time.

Ultimately, we should get to a state where:

 (A) //content can handle any number of simultaneous WebAuthn requests, 
 (B) the embedder can reject requests however it sees fit,
 (C) the embedder can put requests "on hold" before they start (e.g. the API would return a promise, but the discoveries would not start until the embedder says so)
 (D) the embedder can put suspend requests even after they have already started (e.g. the discoveries and device communication would be suspended, so that another request can be started).