Use smile format instead of json for internal Druid process communication.

[surekhasaharan]

For internal communication between Druid processes, switching to a binary format would provide reduction in bytes transferred over the network and better performance.
This should be done for transferring published segments data between coordinator and broker and possibly at other places.

[leventov]

Adding to 0.15.0 milestone as it also concerns internal RPC API (as discussed in #7571)

[gianm]

This doesn't need to be done in 0.15.0, since HTTP supports negotiated response types: the client sends an Accept header with a preference-ranked list of content types that it supports, and the server picks one and responds with it, setting the Content-Type header to the one it chose. IMO, the best way to switch to smile is to adjust things at a deeper layer so all Druid JSON endpoints support this kind of negotiation, and could return either JSON or Smile based on what the client supports and prefers.

[jihoonson]

I don't think all breaking changes in internal API should be a release blocker. And as @gianm said, it can be compatible.

[sashidhar]

Just curious what is the rationale behind choosing Smile amongst myriads of binary encoding formats JSON binary encoding formats like MessagePack, BSON, BJSON etc or others like Protocol Buffers, Thrift, Avro etc.