autoexport: Support none as exporter

[pellared]

Is there a no-op exporter we can use with autoexport?

Originally posted by @james-callahan in #2753 (comment)

[pellared]

From https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md#enum-value:

If a null object (empty, no-op) value is acceptable, then the enum value representing it MUST be "none".

From https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md#exporter-selection:

"none": No automatically configured exporter for [...]

@MikeGoldsmith Do you want to work on it?

[pellared]

How do you prefer func NewSpanExporter(ctx context.Context, opts ...Option) (trace.SpanExporter, error) { to behave when user selects none?

I see following possibilities

Option A - return noopExporter{}, nil

Pros:

1. Ease of use by the user - no special handling
2. This would align with the behavior of autoprop.NewTextMapPropagator

Cons:

1. Performance downgrade. If none is selected then there may be no need to even setup a metrics provider. How the user would know that a "None" (noop) exporter was returned. MITIGATION: We can add a IsNone function so that the user could handle the special case when none is selected.

Option B - return nil, nil

Pros:

1. Easy to implement

Cons:

1. It is bug prone for the user. It may be easy for the user to configure a nil exporter as return nil, nil is not very popular (but it happens). Users may not read the documentation and not handle this case.
2. It requires handling a if exp == nil case

Option C - return nil, ErrNone

Pros:

1. Looks idiomatic
2. If user does not handle the exporter err == ErrNone he will handle it like an error. It is less bug prone than option A.

Cons:

1. This is not really an error.
2. The error handling code may look worse than for option A. In most cases setting a NOOP exporter should be good enought.

I am leaning towards Option A - return noopExporter{}, nil.

@open-telemetry/go-approvers, WDYT?

[james-callahan]

1. Performance downgrade. If none is selected then there may be no need to even setup a metrics provider. How the user would know that a "None" (noop) exporter was returned. MITIGATION: We can add a IsNone function so that the user could handle the special case when none is selected.

I think the selection of exporter should be orthogonal to the metrics provider (and other things).
In particular, I want to be able to turn on and configure propagation, but turn off exporting spans.
If the exporter throws away the span; it's no different to if the user was e.g. using a UDP exporter and experienced packet loss: the exporter saw the span.

---

I think option A makes the most sense. I wouldn't provide any sort of special IsNone function.

[dashpole]

I prefer A as well.