Sanity check: Various Tracer "Expressability"

[ktoso]

This is a final before-stable sanity check that we're able to express all kinds of tracers, we may use a slightly different name for things, but the span should be generic enough to express anything really., i.e. be a superset of core functionality of tracing systems.

We want to check (again):

• [ ] zipkin
  • @ktoso investigating
• [ ] opentelemetry
  • @ktoso & @slashmo investigating
• [ ] jaeger
  • @slashmo investigating
• [ ] plain w3c tracecontext propagation
• [ ] xray
  • https://github.com/pokryfka/aws-xray-sdk-swift
• [ ] honeycomb
• [ ] datadog
  • https://docs.datadoghq.com/tracing/custom_instrumentation/go/
• [ ] various "ad hoc" implementations such as Slack's tracing
  • they don't follow any exact spec, and we want to allow such implementations to also use our instruments -- so they can benefit from the instrumented libraries anyway, even if they do their custom things
  • https://slack.engineering/tracing-at-slack-thinking-in-causal-graphs/

We just want to know that it's possible to carry enough information as an implementation would want to, even if they're not open telemetry or whichever standard compatible. We specifically design this API to be agnostic to any specific standard (we're committed to this), but be flexible enough to implement them.