Turning this into a separate ticket to make it more clear what's been worked on since I started on#16518

Context

As mentioned in the parent ticket, we had a few assumptions about what was and wasn't possible about our WebSocket (WS) and Server-Sent Event (SSE) communication, and these ended up being wrong. Namely, we thought there was no good way to fix the root problem of the UI locking up when multiple tabs are opened, and the best we could do is create a UX band-aid to help direct users from hitting these edge cases.

It turns out, this is a problem that only exists with the Server-Sent Events protocol. Even on HTTP/1.1, all modern browsers support proper duplexing for socket connections. So naturally, if SSEs have the problem, and WSs don't, we can switch everything over to WebSockets.

Concerns

• As of right now, the Coder SDK exposes a lot of Server-Sent Event concerns and types as public exports. We can't have any breaking API changes, so the best we can do is officially deprecate this functionality, and add documentation nudging people to favor WebSockets.

Tasks

• AddOneWayWebSocket function that automatically handles upgrading an HTTP connection to WS, and handles all concurrency concerns
• Add (non-flaky, concurrent) tests forOneWayWebSocket
• Mark all previous SSE-based API routes as deprecated
• Add new API routes that are WebSocket-based