Lazy vs non-Lazy Event APIs

[jmacd]

The API currently has two forms of event API, one supporting non-lazy usage (Event) and one supporting lazy usage (AddEvent). On the one hand, there is a desire to support lazy events. On the other hand, there is a desire not to force allocation of an object for all events.

This may rise to a specification level issue. We have open discussions around SpanData and Sampling and Laziness in general, and it is difficult to separate the event API from this larger discussion.

In OpenTracing, there was support for lazy events, via bulk delivery using an option to the span.Finish() call. I believe the thinking was that sometimes you want to be lazy and limit the number of events that are buffered (assuming they are buffered). See https://github.com/opentracing/opentracing-go/blob/135aa78c6f95b4a199daf2f0470d231136cbbd0c/span.go#L154

At the same time, some OpenTracing libraries added support for lazy values, which are not the same as lazy events. In this case, I believe the thinking was that a programmer is only concerned with avoiding an expensive serialization when the SDK is not recording a span. See https://github.com/opentracing/opentracing-go/blob/135aa78c6f95b4a199daf2f0470d231136cbbd0c/log/field.go#L149

I will propose that we:

1. Eliminate the lazy/interface form "AddEvent", keep the non-lazy/concrete form "Event". Either name will do, it's the behavior that counts.
2. Support bulk lazy events via FinishOptions as in OpenTracing
3. Support lazy values via a new ValueType for lazy serialization

[bogdandrutu]

Lazy events at the end is not necessarily good. For example you force everyone to make these data available in the function that calls end. Also some implementation may want to allow access in real time to these process (what OpenCensus calls zpages active spans).

Another usecase is that you the user to also record a timestamp for these events because they don't happen at the end of the Span.

[bogdandrutu]

My 2 cents here is to eliminate the Event interface and use a concrete type + formatter to avoid allocation when possible and keep that API

[jmacd]

In the OpenTelemetry FinishOptions, each log record has an independent timestamp.

I also support the idea that Event (or AddEvent) should use a concrete type + formatter, it's exactly what I mean when I say "lazy value". Sounds like this will be easy to resolve.

[jmacd]

Today's API reads:

	// AddEvent adds an event to the span.
	AddEvent(ctx context.Context, event event.Event)
	// AddEvent records an event to the span.
	Event(ctx context.Context, msg string, attrs ...core.KeyValue)

I believe we should eliminate one of these. The specification says the method should be named "AddEvent", but we have agreed above in this issue not to use an interface.

Therefore, we should consolidate into one method

   AddEvent(ctx context.Context, msg string, attrs ...core.KeyValue)

and remove the Event interface.