Generic node/range properties

[adammck]

From the brain-dump in #27

// dataAddr returns the remote addr for the given remote, but with the leading 1
// of the port replaced with a 2. This is of course a terrible hack! But rangerd
// has no clue about the port conventions of this cache service, and the mirror
// currently provides no way to smuggle that info across the wire.
//
// Ideally the rangelet would accept some arbitrary blob of bytes (like an empty
// interface, but serializable) which could be included with responses to probes
// and range assignments, like "extra info about this node". Obviously services
// would have to deserialize it themselves.
//
// In the case of this service, the extra payload would be simply:
//   type CacheNodeInfo struct {
// 	   dataPort int
//   }
//
// More complex services may smuggle signals like ingestion or replication lag,
// which clients then use to decide which result to use, although those examples
// sound more like per-range info than per-node...
//
// Services can already, of course, provide endpoints to exchange info entirely
// outside of ranger. But it feels unnecessarily boiler-platey to provide a gRPC
// endpoint just to ask "what is your HTTP port?".

We need some kind of interface for nodes to expose properties about themselves to the rangelet, which are then conveyed to other nodes via the mirror. The controller shouldn't care about this stuff at all; it's just opaque blobs. Possibly service-specific load balancers would also use it, though.

I think this same thing might be useful for ranges, too, but I'm unsure about that. Currently we have api.LoadInfo, which encapsulates how "big" the range is so that external balancers can move/split/join appropriately, but probably there will be other info which would be useful to convey between nodes but Ranger itself doesn't care about it.