Add sdk/metric/reader package structure to new_sdk/main

[MrAlias]

Blocked by #2799

Add in the needed interfaces and high-level types for the new SDK design from new_sdk/example. This is not expected to be a fully working implementation.

sdk/metric/reader

• type Reader interface
  • type Registeree interface (might be a better idea to rename this idiomatic to Go Registerer)
  • type Producer interface
  • type Metrics struct
  • type Scope struct
  • type Instrument struct
  • type Point struct
• type Exporter interface
• type Option interface to be passed to the new Provider method option
  • type config struct stub

[MrAlias]

The Registeree interface is only embedded in the Reader interface. I do not see a reason this should not just become:

type Reader interface {
	Register(Producer)
	Flush(context.Context) error
	Shutdown(context.Context) error
}

[MrAlias]

The current package structure seems like an attempt to consolidate docs of the sdk/metric package instead of an intentional grouping of related concepts. There are interface exported here that are not used in the package, it doesn't match the trace span processor and exporter layout, and it seems to overlap with the sdkinstrument package's purpose.

I think this package structure could use a revised design attempt here before we progress with a PR.

[MrAlias]

After reading the metric SDK specification and looking at other SIG implementations I wonder if we can simplify the readers and make them more concrete in the implementation. Something more along these lines:

type Exporter interface {
	Export(context.Context, Metrics) error
	Flush(context.Context) error
	Shutdown(context.Context) error
}

type Reader struct{}

func NewReader(mp *MeterProvider, exp Exporter, options ...Option) *Reader

func (*Reader) Collect(context.Context) error

func (*Reader) Flush(context.Context) error

func (*Reader) Shutdown(context.Context) error

type PeriodicReader struct {
	Reader
}

func NewPeriodicReader(mp *MeterProvider, exp Exporter, options ...PeriodicOption) *PeriodicReader

This addresses a few issues:

• There is a uniqueness between Reader to MeterProvider that needs to be enforced. Constructing Readers this way ensures that only one MeterProvider is passed to a Reader. There is no extra guards need to handle a registration method.
• Simplifies implementation. There is no need for the additional Registeree or Producer interfaces.
• Each Reader can manage their own pool of Metrics and this optimization of passing an already allocated object to Collect is not exposed to the public API.

Issues with this approach:

• It is not user extensible; users cannot provide their own implementation of the Reader.
  • The Java SIG currently does not allow non-OTel Readers, so there is already precedence here.
  • The specifications language does not indicate this should be user defined.
  • If we want to change this in the future, the MeterProvider can have a Producer method added to it that user Readers can wrap with their Collect operations.
• Initialization of the metric pipeline switches to Reader(MeterProvider, Exporter) or even Exporter(Reader(MeterProvider)) instead of MeterProvider(Reader(Exporter)).
  • The periodic reader case could still be abstracted into a MeterProvicer option like func WithPeriodicReader(Exporter, ...PeriodicOption). This would be similar to the tracing WithBatcher option and, outside of the Prometheus exporter, would be the common use case.
• The prometheus exporter can no longer be an implementation of the Reader.
  • The Prometheus exporter can instead wrap a Reader that it calls (i.e. func New(*MeterProvider, ...Option) *Exporter can create and wrap a Reader)

@jmacd thoughts?

[MrAlias]

Abbreviated feedback from @MadVikingGod in SIG meeting on the above design is the Prometheus exporter needs to call Collect and in the same function scope receive the collected metrics. The new_sdk/example approach does this by implementing a reader and calling Produce.