Adding support for serialized values in formats other than json

We should do three things to allow clients to send objects in more efficient formats - add a new customObjectResult to EncodedValue, add a way for clients to request the serialization format, and add a way to control the serialization format on the server.

Add customObjectResult as an option in EncodedValue

We want clients of the new protocol to be able to send and receive data that is serialized using PDX. We could just add a pdxObjectResult as one of the options in our EncodedValue protobuf message. But instead let's add a customResult and provide a way for the user to serialize a value however they want. PDX can just be of of the options with this mechanism.

message EncodedValue {
    oneof value{
        bytes binaryResult = 8;
        string stringResult = 9;
        string jsonObjectResult = 10;
        google.protobuf.NullValue nullResult = 11;
        bytes customObjectResult = 12;
    }
}

Provide a way to ask for a specific serialization format

We currently always send back PDX objects as JSON values. Because we will now have multiple formats that we need to add a way for clients to request what format they want. We will introduce a new message from the client to control the format that values are sent as. Here again, we could just use an enum with JSON and PDX. But in order to support custom formats let's make it a string so that users can provide their own serialization formats. TODO - should we actually make this a field on some sort of handshake message? Right now we just have an optional AuthenticationRequest

 message SetCustomValueFormat {
    string format =1; //Acceptable strings are JSON, PDX, or the ID of any CustomValueSerializer that is registered on the server
}

Provide a way to register a serialization format on the server

If the users want to serialize values their own way, we need a way for them to plugin their own serialization code on the server. We can provide a CustomValueSerializer like below. The easiest way for us to support a plugin would be to just use java's ServiceLoader mechanism, where the user provides an implementation of the interface and puts a reference to that under META-INF/services in their jar.  This serializer will be invoked on the server whenever we are receiving or sending an EncodedValue. We will call this serializer even for primitive objects like Integer.

public interface CustomValueSerializer {
  String getID();
  /**
    * @return true if the object was serialized, false if not. If this method returns false the server will 
    * fall back on sending the object as one of the primitives in EncodedValue (int, string, jsonObjectResult, ...)
    */
  boolean serialize(Object value, DataOutput out);
  Object deserialize(DataInput in);
}

Registering PDX types

Clients that send PDX values need to be able request PDX type IDs from the server. We can add a new message to request a PDX type ID. But until PDXType and it's serialization format are actually public maybe we should just make this an internal function call, not a new message in the protocol? Since clients that support PDX need to support DataSerializable, we will just have them serialize a PDXType  as a DataSerializable, rather than defining a PdxType in protobuf.

message GetPdxTypeIdRequest {
  bytes serializedPDXType = 1;
}
message GetPDXTypeIdResponse {
  int32 id = 1;
}
message GetPdxTypeRequest {
  int32 id = 1;
}
message GetPdxTypeResponse {
  bytes serializedPDXType = 1;
}