Refactors such that Kafka bundles spans and shares more code

[codefromthecrypt]

This rewrites KafkaSpanCollector to bundle multiple spans into the same
Kafka message. Basically, as many messages that come in one second will
send in the same message. This change resulted in several times higher
throughput in Yelp's kafka+cassandra Zipkin architecture.

Flushing can be controlled via KafkaSpanCollector.Config.flushInterval

Incidentally, this shares a lot of code with HttpSpanCollector, which
should reduce the amount of bugs and maintenance around queue-based
collection.

[kristofa]

Good that we try to share more code between collectors. The queueing and submitting logic was implemented multiple times and can easy contain subtle bugs. Makes sense to abstract and re-use.

[codefromthecrypt]

@kristofa PTAL

[codefromthecrypt]

PS the code would be less complex if we mandated those using Kafka to
update to zipkin 1.35+ collectors prior to upgrading brave. If that
policy sounds OK, I can rip out some dodgy code.

[kristofa]

I think it is fine to ask people who use Kafka to upgrade to 1.35+ collectors. We can add it in the release notes. In that case we can remove the bundlingEnabled config entry and code that deals with it. That's what you mean with dodgy code I guess?

[kristofa]

I also like the approach with flushInterval=0 for testing. Makes tests a lot more reliable if we don't have to deal with background thread. 👍

[codefromthecrypt]

ready to go

[kristofa]

Not sure why travis build is unhappy. Tests run fine in my local environment. Will merge.

[kristofa]

@adriancole After merge master build is failing. There was a warning about missing version for maven-shade-plugin which I fixed but I can't see build log for latest 2 builds... (latest one: https://travis-ci.org/openzipkin/brave/builds/113873969) any idea what is wrong?

[kristofa]

I can't reproduce build failure in my local environment.