Support a longpoll transport fallback when WebSocket connections are blocked

[joelbyler]

I'm looking at a workflow where an Elixir Slipstream client runs on an edge device, on customer networks where WebSocket connections are sometimes blocked (proxies stripping Upgrade, etc.). The Phoenix JS client handles this with longPollFallbackMs — try WebSocket, silently fall back to the longpoll transport, same channel API either way — but nothing equivalent exists for non-JS clients today.

What are your thoughts on supporting something similar here? I can see two shapes: making the transport pluggable in Slipstream.Connection (a longpoll transport could then live in-tree or out), or keeping Slipstream WebSocket-only and blessing a companion library that wraps it with the fallback policy. Possibly related: #75 describes a hang on exactly the can't-establish-WebSocket case a fallback would address.

Happy to help contribute to the work if there's interest — wanted to gauge direction before writing code.

[the-mikedavis]

Interesting question! Slipstream is pretty intertwined to websocket and long-poll is pretty different, so I'm not sure I would want to build long-poll in. I think that introducing some kind of transport interface/behaviour in Slipstream might work best, so a long-poll implementation can reuse the joins/rejoins/refs/heartbeats/etc logic. With #88 it should be possible to detect upgrade timeouts and switch to long-poll.