Rewrite the createOffer algorithm to eliminate race conditions.

[taylor-b]

First step in addressing #782. Though the resulting algorithm is pretty
ugly and could probably use some restructuring.

[taylor-b]

@jan-ivar, can you take a look? A couple things to note:

This only covers createOffer so far. I'll handle the other methods (createAnswer, SLD, SRD) later, but first I want to make sure I'm on the right path.

And as mentioned in the description, the algorithm ends up pretty ugly. It's essentially 4 levels of nesting, with GOTOs. If it was source code, I wouldn't "lgtm" it myself. Do you think it would be appropriate to restructure it, creating multiple "steps to do X", "steps to do Y" etc. subsections? Something like this:

To obtain an identity assertion before running steps s, given promise p:

1. Let idpPromise be the promise returned by the IdP proxy.
2. Upon fulfillment of idpPromise, run s, given p.
3. Upon rejection of idpPromise, reject p.

To prepare to create an offer given promise p:

1. In parallel:
   1. Do parallel stuff.
   2. Queue a task to perform the final steps to create an offer given p.

The final steps to create an offer given promise p are as follows:

1. If IdP has changed, obtain an identity assertion before preparing to create an offer given p and abort these steps.
2. If PC state has changed, prepare to create an offer given p again and abort these steps.
3. Make offer and resolve p with it.

I've noticed the "web APIs" section of the HTML spec (for example) does this kind of thing all the time. It very rarely has more than 2 levels of nested tasks.

[adam-be]

I'm not sure how the PR text works with the two returns of p (both step 4.).

I think we should give the approach with subsections a try. I'm not sure where the execution in the above description starts and what s is.

[taylor-b]

That was something I noticed, but I thought maybe the extra return wouldn't hurt anything. In any case, I'll work on the alternate flavor of this PR.

Also, I got to thinking, maybe the identity assertion race condition (calling setIdentityProvider after createOffer) should be handled in some other way? Using two identity providers would be terrible user experience anyway (I assume) so this is something that should never happen. I'll try moving "begin identity assertion request process" to the synchronous section for this PR.

[taylor-b]

See alternate PR above. I think the identity provider part still needs to be formalized better, but that can probably happen separately.

[adam-be]

I think we can close this PR in favor of #875.

[stefhak]

Closing as it is superseded by #875 .