Delayed Span and Span Links

[ivantopo]

This PR introduces two features that we recognized as necessary while moving modules to Kamon 2.0:

Span Links

It happens some times that we have Spans that do not necessarily share a parent/child relationship, but that are related to each other. For example, when tracing operations that go through a message broker (e.g. Kafka), the decision of whether the producer and consumer spans should be part of the same trace will depend on domain-specific implementation details (see note 1) and for those cases in which we will want separate traces we can use a link to keep a reference to the initial span/trace id.

Delayed Spans

Delayed Spans are a special kind of Span that track operations which that do not start processing immediately after the Span is created but after some period of time. In general, delayed Spans work pretty much the same as a normal Span but they have the ability to record two new additional metrics:

• span.wait-time: tracks the time between creating and starting a Span.
• span.elapsed-time: tracks the time between creating and finishing a Span.

The previous span.processing-time metric remains the same as before.

    
  Created
     |=====================|                                          <- Wait Time
     |====================================================|           <- Elapsed Time
                           |==============================|           <- Processing Time
                        Started                        Finished

This new abstraction is specially interesting in (but not limited to) two scenarios: first is when tracking Futures since they can be created at a given point in time but the execution will start at a later point when their executor allows them to, and second, when tracking message consumers that can know when a message was put into the message broker. To avoid yet another Span implementation I put all the behavior on the same Span.Local class and the exposed interfaces will narrow what users can do or not with a Span.

---

Note 1: I happen to believe that when the message processing has some sort of real time end-user effect I want to have them on the same trace but for async operations where the delay could be big I would prefer to have them as separate traces, but have a way to link back to the trace that produced the original message.

[dpsoft]

@ivantopo LGTM!!

[ivantopo]

Great! I'll continue to work on some instrumentation modules and unless I find something weird I'll merge this and publish Kamon 2.0.0-M4 🎉