[fetch] Network policies should be enforced asynchronously (#161)

We should make all network policies be enforced asynchronously. Including things like CSP, mixed-content-blocking and same-origin checks.

So for example

```javascrip
x = new XMLHttpRequest();
x.open("GET", uri);
x.send();```

should not throw an exception from neither the `.open` call, nor the `.send` call even if `uri` violates CSP policies for the page.

There's a few reasons for this.

* Authors have to deal with network requests failing asynchronously anyway. By also throwing exceptions we require authors to handle both synchronous and asynchronous errors.
* Only some policies can be enforced synchronously. For example enforcing that a redirect follows same-origin policies can only be done after a network request, and so obviously has to be asynchronous. It would be better if all CSP policies are reported the same way, rather than have some reported synchronously and some asynchronously.
* At least Gecko's network implementation is currently main-thread-only. Including essentially all of our uri handling. This means that we have to do things like CSP checks on the main thread. That makes it problematic to make these APIs throw on workers. It's certainly not impossible, but it adds significant performance and complexity overhead.
* I'd like to move much more of our network security policies into our network stack. If these checks are asynchronous, it means that we can keep all communication with the network stack asynchronous and can report things like CSP errors and network errors through the same code paths. I.e. we can keep a simpler implementation which means fewer bugs. This is especially important since error conditions are notoriously poorly tested, and so having fewer error reporting paths is especially beneficial.

One example where synchronous errors are required is step 5 in:
https://html.spec.whatwg.org/multipage/workers.html#dom-worker
One problem there might simply be that workers need to integrate with the fetch spec.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/161