[mnm] Better serialization support for management

[mathieucarbou]

• control serialization
• avoid impacts with serialVerionUid
• performance

This is a copy of Terracotta-OSS/terracotta-management#44 (old management repository)

[mathieucarbou]

IDEA: create an ObjectMapper on top of Runnel

[mathieucarbou]

Things to take in consideration:

• all management classes (model, topology, stats, notification, etc) represents 45 serializable classes: Runnel could help here because we can define the structures of these objects in an entity codec.
• management must support management calls, so it means that we do not know in advance which objects are passed as parameters and which objects are returned. So Runnel cannot help here.

Other things to look at: would it be possible to use 2 different serialization mechanisms for the same entity, depending on the method called, when using the the voltron-proxy module ?

I.e. Runnel codec where we know the objects transferred, and java serialization codec when we do not know the transferred objects (this is true only for methods handling management calls).

[anthonydahanne]

As far as I understand runnel, it's meant to be used with known classes : so that the user defines precisely how objects should be (de)serialized.
So I like the idea of using runnel for classes we know (and that represent a performance bottleneck because of their very frequent use : stats, notifications) and default serialization for the rest (model, topology)

[GaryWKeim]

I'm in the process of adding a version to the client topology model so that it will be included in cluster state dumps. To avoid backward compatibility issues I resorted to putting the version in the tag collection and then remove it on the other side. We need a better compatibility story here.