1. Define Protocol Format Definitions

[juanpedromoreno]

After discussing the best approach it makes sense to divide the RPC framework into three main building blocks. Protocols, Server, and Client.

This issue addresses some of the main concerns when defining the protocol piece.

1. Protocols should be defined in a separate module to avoid server and client specific dependencies.
2. Protocols will be defined as scala traits in code and will derive proto files automatically for other langs and frameworks to consume those. This will enable Freestyle microservices to be consumed from any lang that or framework that support codegen from proto file.
   The proposed protocol declaration for a service is as follows:

  @service
  trait Greeter {
    @rpc def sayHello(msg: MessageRequest): FS[MessageReply]
    @rpc def lotsOfReplies(msg: MessageRequest, observer: StreamObserver[MessageReply]): FS[Unit]
    @rpc def lotsOfGreetings(msg: StreamObserver[MessageReply]): FS[StreamObserver[MessageRequest]]
    @rpc def bidiHello(msg: StreamObserver[MessageReply]): FS[StreamObserver[MessageRequest]]
  }

  @message case class MessageRequest(name: String)
  @message case class MessageReply(message: String)

The service and messages definitions above will generate the following .protofiles

syntax = "proto3";

package freestyle.rpc.demo;

service Greeter {
    rpc SayHello (MessageRequest) returns (MessageReply) {}
    rpc LotsOfReplies(MessageRequest) returns (stream MessageReply) {}
    rpc LotsOfGreetings(stream MessageRequest) returns (MessageReply) {}
    rpc BidiHello(stream MessageRequest) returns (stream MessageReply) {}
}

message MessageRequest {
    string name = 1;
}

message MessageReply {
    string message = 1;
}

3. The protocol module will also be responsible for including @free representations of the traits to be used in a process outside of RPC concerns. A special version of the abstract handler will also be generated containing the stubs necessary for Servers to be hydrated given a list of @service protocol types.
4. Is not the responsibility of this module to generate any kind of server or client code and should remain decoupled from those concerns.

[juanpedromoreno]

Superseded by #28 and #29