Protocol: standartize error codes, disconnect codes, client and subscription statuses throughout connectors

[FZambia]

At the moment we give access to string reason, but not to disconnect code. I suppose we should expose access to the code too.

[FZambia]

There are cases when client disconnected due to network conditions, timeout, etc. In these cases, there is no disconnect code from a server available. The simplest solution is providing 0 as code in disconnect context. But I suppose it may be better to standardize client-side codes for these situations:

• CleanDisconnect: 0 false
• TransportConnectError: 1 true
• TransportWriteError: 2 true
• TransportReadError: 3 true
• TransportClosed: 4 true
• ConnectFailed: 5 false
• RefreshFailed: 6 false
• Unauthorized: 7 false
• Unrecoverable: 8 false
• ConnectTimeout: 9 true
• SubscribeTimeout: 10 true
• NoPing: 11 true
• Slow Client: 12 true
• UnsubscribeError: 13 true

All client-side disconnects except clean disconnect result in a reconnect.

P.S. A good thing would be also think about client-side error codes.

[FZambia]

Possible client errors and codes:

• TransportConnectError = 0
• Timeout = 1
• TransportWriteError = 2
• ClientDisconnected = 3
• SubscriptionUnsubscribed = 5
• SubscriptionClosed =

[FZambia]

Also, for the future would be great to standardize client connector statuses. One possible option is having:

• DISCONNECTED
• CONNECTING
• CONNECTED
• CLOSED

Relates centrifugal/centrifuge-swift#27

[FZambia]

And subscription statuses (not actual - see UPD below):

• UNSUBSCRIBED
• SUBSCRIBING
• SUBSCRIBED
• ERROR
• CLOSED

UPD: things evolved here a bit, current plan is to have:

• UNSUBSCRIBED
• SUBSCRIBING
• SUBSCRIBED

[FZambia]

Also, looking for a way to avoid using JSON string as reason in disconnects. I think we may somehow use code to indicate whether or not client should reconnect (odd/even?). And send plain text reason. Not sure how to do this in backwards compatible way though.

Done in #221

[FZambia]

If someone follows this issue – the current draft of standartized client API is in Centrifugo v4 WIP docs:

Client API v2

Any feedback is appreciated – this is the future of Centrifuge and Centrifugo.