Tracking of remote services calling an instrumented service

[ivantopo]

The idea is simple, if we have services A, B and C calling service X, from the perspective of service X we should be able to tell Kamon to keep track of the remote service issuing the calls, so that metrics can be help us identify the traffic sources. At a minimum, the following changes would be needed:

• When an instrumented service issues a call to another service, it always propagates its own identity when issuing the call. So, when A calls X, it adds in-band information specifying its identity.
• When an instrumented service receives a call it will search for the remote service name propagated in-band and add it as a tag to the correspondent tag or metric.

I think that with the introduction of context tags in #552 we have a very good candidate medium for propagating this information, but there are a few additional things that would need to be defined in order to move forward:

• Up until when should a remote service identifier be propagated? For example, if X creates a Server span, then 3 local spans and then makes a remote call to another service, it is obvious that the server Span will have the remote caller in there, but should the other local spans and the downstream call have that information as well? all in all, the remote service is "responsible" for making service X do all of these calls, but it might be a bit weird to have a bunch of Spans from service X mentioning service A.
• What should be the mechanism for transferring this information? As I said above, context tags seem like the right tool for the job.

There was a related conversation in gitter with @adriancole: https://gitter.im/openzipkin/zipkin-dev?at=5bbdd507600c5f6423836bca where there are some additional insights. Also... this issue focuses on the server side of things, but we might want to think about a nice way to handle client calls to uninstrumented services, in which case the client should provide some sort of identity of the remote service (e.g. calling a MySQL database).