Expose OpenTelemetryController as interface option to Instrumentation

[damemi]

Ref #1026

This does two things:

• Create an interface for OpenTelemetryController so it can be overwritten (collector receiver needs to push to next consumer as ptrace, rather than exporting otlp to an endpoint)
• Exposes the probe.Event struct (which is the parameter to the Trace() function in the OTelController interface)

[RonFed]

LGTM
As we talked in the SIG, I think we need to add some comments about the probe.Event struct and its fields, and maybe rename them since SpanEvent is a misleading name (maybe SpanData?)

[damemi]

LGTM As we talked in the SIG, I think we need to add some comments about the probe.Event struct and its fields, and maybe rename them since SpanEvent is a misleading name (maybe SpanData?)

I added some comments, but don't want to make too many changes like renaming the struct in this PR if that's ok with you

[MrAlias]

I'm hesitant to export this type.

I just noticed that the start/end time are not actually unix timestamps, but the relative offset from startup.

I think we need to better evaluate the structure of this event type before we publish something others will rely on. It might make the most sense if we actually use a proto representation of spans similar to the collector's pdata approach. That way we could avoid deserialization if an exporter speaks that protocol.

[damemi]

@MrAlias I pushed an update adding a wrapper struct that gives us a public abstraction from the internal types. Ideally I think we should eventually just take a good look at the internal types and make them public, but something like this could give us a nice bridge to that. Wdyt? Open to ideas