Protocol features and handshake

[Mr3zee]

Problem Description There might be cases when client and server that should talk are different versions of the library and thus some protocol logic/features.

Solution Introduce handshake phase of the protocol, during which endpoints exchange lists of the plugins they support and then act accordingly

Details

• We introduce more hierarchy to RPCMessage. Now the root class is RPCAnyMessage with two primer descendants: RPCMessage - for service messages and RPCProtocolMessage - for utility messages, like handshake.
• We introduce RPCPlugin and RPCPluginKey enums, which are responsible for communication style.

[Mr3zee]

So, thanks to API dumps this review looks big again...

Where to look for juicy details:

• RPCConnector.kt
• KRPCClient.kt
• KRPCServer.kt
• RPCMessage.kt
• RPCPlugin.kt
• RPCPluginKey.kt
• ProtocolTest.kt

[Mr3zee]

Good news: API tests are working and I was able to easily make sure that this change is backward compatible with old clients!