Add interfaces for exporter, processor and span data

[pyohannes]

This PR adds:

• interfaces for exporters and processors
• an implementation of the simple span processor required by the spec,
• an implementation of the default SpanData recordable.

[g-easy]

Events? Is that TODO?

[pyohannes]

Yes, for now I left events (as well as attributes, links and resources) out on purpose. I'd like to handle that in a separate PR.

[reyang]

LGTM.

[pyohannes]

As discussed on Monday, I added implementations to test the interfaces:

• SpanData for the Recordable interface. This can be used by exporters that don't provide their own Recordable implementation.
• SimpleSpanProcessor for the SpanProcessor interface. The simple span processor is defined in the spec.
• A mock span exporter for the SpanExporter interface, used in tests.

[rnburn]

Could we combine SetTraceId, SetSpanId, SetParentSpanId into something like SetSpanContext(trace_id, span_id, parent_id)? For eager serialization implementations, it's common for them to be written together as a group.

[pyohannes]

Makes sense. I think SetSpanContext is a bit ambiguous, as the concept of SpanContext has a different meaning int the spec. I went with SetIds instead.

[rnburn]

The convention we've been using is to name tests with a "_test" suffix (e.g. trace_id_test, span_data_test). See, for example,
https://github.com/open-telemetry/opentelemetry-cpp/blob/master/api/test/trace/BUILD#L42-L51

[rnburn]

s/simple_processor/simple_processor_test/

[rnburn]

Looks good. I think we'll need some tweaks to the exporter to

1. Work with span circular buffers where the data isn't stored in a single contiguous segment.
2. Support forking (needs something like a restart function)
3. Support streaming exporters.

But I'm good merging in and evolving.

[pyohannes]

I added a new issue for the remaining open points: #62

With this in mind, I think this PR can be merged.

[bogdandrutu]

Some initial feedback about exporters and span data.

[bogdandrutu]

Why is this in the interface? Do I need to implement this function in order to implement an exporter?

[rnburn]

That's to allow for more efficient implementations.

It's expensive to build up a SpanData-like object that provides an accessor interface. Having this as a customization point, allows for direct serialization approaches where memory is allocated in larger blocks and the serialization is built up eagerly as methods on the tracer are called (I outlined the approach in #2)

See, for example, this benchmark from lightstep's cpp tracer where we compare a custom eager serialization approach (manual) to a SpanData-like appraoch that uses protobuf-generated objects (legacy_manual). The results show that the cost can be substantially less (ranges from 2x-5x in that run). If you look at the profiles (manual vs legacy_manual), you'll see the eager serialization approach saves a lot from avoiding small memory allocations.

But there's a SpanData Recordable in the SDK, so if an implementer doesn't want to provide their own Recordable, they can write MakeRecordable as a stub that returns a SpanData.

[bogdandrutu]

Why is this in the interface? Do I need to implement this function in order to implement an exporter?

[pyohannes]

Yes. For non-optimized cases, the exporter can return a SpanData instance, which derives from Recordable.

There are good descriptions and discussions about this approach in this PR. It's shown in action here.

[bogdandrutu]

In other languages Recordable is not an interface but a concrete immutable class.