Ember WebSocket on 0.22

[RaasAhsan]

Supersedes #4765. Copying the old PR description over:

Introduce initial support for the WebSocket API on Ember Server. The main goal here is to comply with the existing WebSocket model; refinements are going to come through in followups. The work here is pretty straightforward to the point that I have an appetite to implement a WebSocket client as well. I think that is uncharted territory though.

Something I've been thinking about is whether we want to release this immediately or wait (maybe we release on 1.x, maybe we wait for some followups to complete). I'm not personally a huge fan of long-lived development branches, but we could merge and let the code sit on mainline without exposing a flag to enable it. FWIW, I think this PR will be fairly easy to merge forward to main.

TODO:

• Think about how to expose websocket support
• Cover all error scenarios and ensure proper resource cleanup
• Address all the TODOs scattered around
• Rely on a custom WebSocket parser rather than the existing FrameTranscoder?
• Tests and benchmarks
• Address old PR comments

[RaasAhsan]

Nearly done here with the PR. Just need to consider what happens in various error scenarios and respond appropriately. And I think I'll slide in some tests

[rossabaker]

So the Circe release is imminent, which was our trigger for 0.22.0. We need to decide if this is still going into 0.22, or held back for 1.0. We're probably looking at early this week. Maybe do an RC for Rho's sake.

[rossabaker]

In Blaze, we opt into web socket support by wrapping another stage, but it's one more thing to trip over configuring for users. I'm not sure the opt-in is worth it.

[RaasAhsan]

I wonder if we could be a bit smarter here for keep-alive connections. If we know we're on one, the upgrade should never happen. I may do some performance tests later, but since this is on a 0.22 milestone I may just defer as a follow-up since opt-in is something we can add in later

[rossabaker]

If there's nothing ember here, a more general internal package might be good. There's renewed talk of servlet support, and it would look a lot like this with servlet's HttpUpgradeHandler.

Although if it's all internal, we can refactor it later. Meh. It's fine where it is.

[RaasAhsan]

There isn't much ember-specific but it does rely on fs2's Socket, which we should be able to abstract over with some effort. I've been wanting to do that anyway so we can write some tests with more depth

[rossabaker]

This has been targeted at 0.22, but it can slip. Tagging it so we decide.

[rossabaker]

It looks like this is all additive, so we don't need to agonize over whether it makes the 0.22.0 bus. We can introduce it in a patch if it's wanted in 0.22.

[RaasAhsan]

Going to clean up and add some tests, and should be in a good spot to merge

[rossabaker]

This is looking good. Anything we can't lock into 0.22.0 and 0.23.0?

[RaasAhsan]

I don't think there are any public API changes here. thought about exposing an option to enable this for performance since blaze had one but I was going to look more into that as a follow up. When are you planning to cut the 0.22.0 and 0.23.0 releases ?

also I can take care of the downstream merges

[rossabaker]

I would love to cut those releases this week, but I'm on vacation, so my OSS estimates depend a lot on the local weather.

An option should be implementable without breaking bincompat, if deemed worthwhile.