Support opt-in async network events

[jdm]

This implements a framework for opting in to receiving network events asynchronously. It also converts XMLHttpRequest to use them, and paves the way for better support for synchronous XHR using on-demand, targeted event loops instead of spinning the global event loop. This gives us complete feature parity with the existing XHR implementation, using fewer threads than before in the async case.

[highfive]

Warning

• These commits modify unsafe code. Please review it carefully!

[jdm]

eb34a78 will be removed before merging; it's just an import of #5139.

[jdm]

@pcwalton Here's a smattering of relevant code to be evaluated for sandboxing concerns:
https://github.com/servo/servo/pull/5156/files#diff-3794c50e22356e01d16b66e3c3d15f46R227 - focus o n the new Listener branch here, as the Channel branch will be removed once all existing code is converted. We invoke a trait method in the privileged process which ends up sending the closure to the sandboxed process to be executed in the target task.
https://github.com/servo/servo/pull/5156/files#diff-a7309719ac3764589527303acba5a1bfR9 - the support code for passing events between the network thread in the privileged process and the target thread in the sandboxed process. Note that script_chan is just a trait object that provides an interface to send events to an event loop - this might be an existing channel, or a brand new one, as described in the next section.
https://github.com/servo/servo/pull/5156/files#diff-016eef304e69674de212b7fbcd9330fdR1042 - This is the code that initiates the request from the sandboxed process. The bit I'm worried about here in terms of sandboxing is in the handling of sync XHR - we create a new channel and make that the target of the async events instead of the regular existing script task event loop; for async requests we use the existing channels.

[jdm]

Huh, this never got a Critic review. I guess the review that's happening in #5197 can serve the same purpose.

[pcwalton]

I'm not sure about passing closures cross-process, in general, since closures aren't Encodable. But perhaps a code pointer plus an Encodable set of data that works like a closure would work.

[hoppipolla-critic-bot]

Critic review: https://critic.hoppipolla.co.uk/r/4448

This is an external review system which you may optionally use for the code review of your pull request.

In order to help critic track your changes, please do not make in-place history rewrites (e.g. via git rebase -i or git commit --amend) when updating this pull request.

[metajack]

@pcwalton has agreed to take this one.

[pcwalton]

Overall this looks pretty solid, but I'm not a big XHR expert. I'd like someone who's more intimately familiar with the XHR code, maybe @Manishearth, to take another look.

[Manishearth]

I'll have a look tomorrow.

[pcwalton]

@jdm r=me with rebase

[jdm]

@bors-servo: r=pcwalton,Manishearth

[bors-servo]

📌 Commit d0704d1 has been approved by pcwalton,Manishearth

[bors-servo]

⌛ Testing commit d0704d1 with merge 3151497...

[bors-servo]

☀️ Test successful - android, gonk, linux1, linux2, mac1, mac2