Fixes #217

This is an implementation of protocol changes described in #217 . Protocol v2 also includes refactoring of disconnect usage: see #221.

Migration plan

For now new protocol is not used by default and can be enabled with ProtocolVersion option of WebsocketConfig and SockjsConfig. It's considered experimental for now but current plan is to make it default in the future.

• Release v0.20.0 with possibility to turn on experimental ProtocolVersion2 for handlers
• Release client connectors (centrifuge-js and centrifuge-go at least) with option to enable ProtocolVersion2, exposing disconnect code only for ProtocolVersion2
• Release Centrifuge with ProtocolVersion2 used by default and possibility to set ProtocolVersion1
• Release client connectors with ProtocolVersion2 used by default and option to enable ProtocolVersion1
• Release client connectors which only support ProtocolVersion2
• Release Centrifuge with ProtocolVersion2 only and remove ProtocolVersion1 support

Migration of Centrifugo

For Centrifugo this will mean 2 possible options.

Option 1

• In v3 adopt v0.20.0 but enable using ProtocolVersion1
• In v4 we will make v2 the default, but still need to support v1 for some time. v1 routes will be the same, so old clients will continue to work. When using clients with ProtocolVersion2 used by default users will need to connect to new route like /connection/websocket/v2 - i.e. explicitly change connection address.
• In v5 we will remove support for protocol v1.

Option 2

• In v3 adopt v0.20.0 but enable using ProtocolVersion1
• In v3 we allow changing handlers to use ProtocolVersion2 by default with "use_client_protocol_v2": true
• In v4 we will make v2 the default, but still need to support v1 for some time. Users will be able to set "use_client_protocol_v1": true so routes will use v1 by default and existing connectors will work fine. To enable using v2 users will set ?cf_protocol_version=v2 in URL. As soon as all clients migrated to v2 developers can remove option "use_client_protocol_v1": true from configuration. Since this moment ?cf_protocol_version=v2 may be removed from client connection URLs.
• In v5 we will remove support for protocol v1 by removing use_client_protocol_v1 option.

Other changes

• IsPush flag of TransportWriteEvent removed
• Force stream epoch from the application code - see Force stream epoch from application code #219
• Less allocations during Hub message broadcast and during client protocol command-reply communication
• Publication Meta field to set custom key-value string pairs, will be exposed to the client-side
• Warn log level added between Info and Error
• Survey accepts one more argument to optionally set a single node where to send Survey request

Benchmarks

Show allocs during message broadcast (this is sync, includes allocs from client side and involves network RTT – so we are mostly interested in number of allocs total here)

Before

BenchmarkWebsocketHandler/JSON-12           	   49245	     23511 ns/op	     945 B/op	       9 allocs/op
BenchmarkWebsocketHandler/Protobuf-12       	   52798	     22965 ns/op	     913 B/op	      10 allocs/op

After:

BenchmarkWebsocketHandler/JSON-12             	   52063	     23100 ns/op	     841 B/op	       7 allocs/op
BenchmarkWebsocketHandler/Protobuf-12         	   53863	     22578 ns/op	     809 B/op	       8 allocs/op
BenchmarkWebsocketHandlerV2/JSON-12                       	   51567	     22757 ns/op	     936 B/op	       7 allocs/op
BenchmarkWebsocketHandlerV2/Protobuf-12                   	   54100	     21975 ns/op	     776 B/op	       7 allocs/op

Show allocs during command-reply RPC (this is sync, includes allocs from client side and involves network RTT – so we are mostly interested in number of allocs total here)

Before:

BenchmarkWebsocketHandlerCommandReply/JSON-12         	   34285	     36057 ns/op	    1641 B/op	      19 allocs/op
BenchmarkWebsocketHandlerCommandReply/Protobuf-12     	   36219	     33355 ns/op	    1626 B/op	      20 allocs/op

After:

BenchmarkWebsocketHandlerCommandReply/JSON-12 	   34132	     35074 ns/op	    1746 B/op	      15 allocs/op
BenchmarkWebsocketHandlerCommandReply/Protobuf-12         	   35504	     33511 ns/op	    1730 B/op	      16 allocs/op
BenchmarkWebsocketHandlerCommandReplyV2/JSON-12           	   34578	     34990 ns/op	    1700 B/op	      13 allocs/op
BenchmarkWebsocketHandlerCommandReplyV2/Protobuf-12       	   35194	     33355 ns/op	    1706 B/op	      14 allocs/op

TODO:

• Check suffixing with /v2 is possible in Centrifugo Most probably will go with Option 2 for Centrifugo migration
• Check how protocol v2 affects real-time connection tracing. Tracing will require adjustments since we used result.Data for pushes as json RawMessage in tracing event.