Support using just the websocket transport

[taion]

This works when using the JS client. That client starts off using just the first transport: https://github.com/socketio/engine.io-client/blob/1.8.2/lib/socket.js#L227. There's a few extra LoC to properly set the timeout on the WebSocket transport, but I believe otherwise things work like this.

[taion]

The motivation here is that we have some Socket.IO servers where we're not using any of the fallback methods, but where (for the moment) the abstraction offered by Socket.IO is valuable enough to justify paying the overhead of Engine.IO, even though we're not getting anything out of it.

We don't want to have to deal with sticky LB sessions, so we only enable the websocket transport.

[taion]

How does this look?

[taion]

Following up here. Is there anything I'm missing for this PR?

[taion]

@invisibleroads Ping!

[invisibleroads]

@taion
If I understand correctly, your pull request lets a client connect directly using the websocket transport, bypassing the initial xhr polling. Is that right?

[taion]

That's the idea. This brings things a bit closer to the logic on the Engine.IO JS client side, which doesn't special-case any of the transports on initial connect (it always tries the first listed transport, then negotiates available upgrades with the server).

[taion]

Any updates here?

[taion]

Ping.

[taion]

Any update here? This has been sitting around for a while now. This is a use case that is present in the JS client, and is essentially required when not using sticky sessions on the backend.

[taion]

What's blocking this PR?

[taion]

Any updates?

[taion]

Ping.

[chirag04]

@invisibleroads any updates on this?

[taion]

Ping!

[akimul]

@invisibleroads Any update on this PR?