Add multi-get support

[npm1]

While our current focus is on allowing multiple IDPs to be supported from a single get() call, there are use cases where this is insufficient, so we should also have a path towards allowing multiple independent IDPs to be shown in the FedCM UI of a page.

[npm1]

My hot take: let's solve this with dynamic UI (show accounts as they become available). Maaybe add a method for RP to mention which IDPs it expects as well? Although that method risks adding a lot of complexity (wait until when?)

The other issue with multi-get is that parameters may be mismatched: what happens with different rp contexts? Different mediations? different modes? etc

[npm1]

Hmm I thought about dynamic UI today and it has really tough issues. For example, how does auto reauthentication work with it? Example:

• First request comes in, with one IDP and mediation optional.
• First set of accounts come in, and it turns out there is a single returning account. The browser accepts that account as valid for auto reauthentication!
• Second request comes in, with an IDP and mediation optional...
• If the accounts are fetched, let's assume this IDP also would return a returning account. This means auto reauthentication should not have happened!

Given this example, I am less convinced that dynamic UI provides a meaningful solution to this problem. We also have evidence showing waiting until onload might be too long. And if we pick an arbitrary cutoff in time, we will end up with a flaky API where in some cases some IDPs will make the cutoff and in other cases it will not. This is very unsatisfying.

One thought: given that there is currently no such thing as multi IDP UI, could we request RP changes? Granted, the calls should be isolated enough and largely be organized by the IDP. But what if we asked the RP to tell us how many IDPs it has that use FedCM? That is, suppose we add a method waitForFedCMRequests(numRequests). The RP would call this method before embedding the IDP scripts, to ensure no flakiness. Once this method is called, the browser would know it needs to wait for numRequests in order to show UI afterwards. Now, this still leaves the browser with the flexibility of saying 'this IDP took too long', removing it from consideration in case there are cases where an IdP is taking too long to respond to the FedCM fetches, so that the other IdPs are not blocked forever. It also provides a deterministic path towards allowing multiple get calls to work independently, at least under the scenario where an IdP always invokes FedCM when told to do so, as otherwise the browser will be stuck waiting for a call that never happens.

If anyone has thoughts on this idea (either 'great idea' or 'here is a problem with this'), or any other idea to solve this problem, feel free to chime in!