Update WebSocket construction per mixed content

[domenic]

Per https://w3c.github.io/webappsec/specs/mixedcontent/#websockets-integration, the preferred behavior for mixed content web sockets is not to throw a SecurityError during construction, but instead block the connection, just like with other network APIs.

Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=28841.

@mikewest, saw this lonely bug over there and thought I'd fix it for ya.

[mikewest]

LGTM, though until the protocol bits are updated with http://www.rfc-editor.org/errata_search.php?rfc=6455&eid=4398, this leaves things fairly broken. I think @annevk was looking into bringing that into Fetch? :)

[annevk]

No we should not merge this. See #180. We should make a plan first.

[annevk]

I tried to figure out a plan, but it's unclear to me what is best. Clearly it would be better if some of the API-level requirements became network-requirements instead, but currently we have no control over the network. Perhaps maintaining a (big) monkey patch in HTML is the way to go? Figuring out if we can reuse Fetch in some fashion also still seems attractive, since duplicating all the requirements is kind of cumbersome.

[domenic]

@annevk I'd like to either merge this or close the PR and re-open the bug. To me it seems like an improvement over the status quo, but maybe not. Happy to go with whichever you decide.

[annevk]

I think doing this in isolation doesn't make the WebSocket situation clearer, since we have landed HSTS earlier.

We should first decide where they happen API or network (probably most of them network) and then write a monkey patch on top of the crappy RFC. Maybe Fetch should provide all the relevant WebSocket network hooks and then Fetch can handle all the necessary monkey patching.

Would love to know what @mikewest thinks if he can still remember.

[domenic]

OK. I will close this and re-open the bug then.