Remove No-Op instrument and Meter creation restrictions

[MrAlias]

The current No-Op requires all instruments to be created from a Meter and a Meter to be created from a MeterProvider. This was inherited from the SDK specification, but it is not necessary. The No-Op performs no operations and hold no state, therefore creating these objects directly should not have logical or processing consequences. If there are consequences of doing this in a language implementation, they are still permitted to keep this restriction.

This change is desired by the Go SIG. We want to export these No-Op types so users can create them directly. This will allow them to embed these No-Op types in their SDKs to define default behaviour, and allow them to use them directly for testing (instead of having to go through the creation chain all starting with a MeterProvider).

[jack-berg]

Java forces users to go the meter provider -> meter -> instrument chain, and we'll probably stick to that for now, but it seems like a reasonable request to be able to jump to instruments directly.

[yurishkuro]

This change is desired by the Go SIG. We want to export these No-Op types so users can create them directly.

I don't understand the motivation. Code can always do new(NoopProvider).createMeter().createInstrument() without changing the spec.

[Aneurysm9]

The types need to be exported to be able to be embedded in SDK implementations. If they are exported they can be created directly. If they can be created directly then the implementation is not spec compliant.

[yurishkuro]

Only NoopProvider needs to be exported in my example, not the individual instruments.

[Aneurysm9]

The issue is not with reference to instances of the type, but the type identifier itself. To embed a type it must be referenced where it is to be embedded. To reference a type outside of the package where it is declared it must be exported.

type MyCounter struct {
    noop.Int64Counter
    // other fields
}

No instances of the type are involved and being able to create an instance of a noop.int64Counter from a noop.meterProvider doesn't matter when I need to reference noop.int64Counter and cannot unless it is noop.Int64Counter.

[MrAlias]

@carlosalberto can we include this in the upcoming release?

[jmacd]

markdown-link-check :(

[MrAlias]

markdown-link-check :(

That failure doesn't look related to these changes. It looks like another PR is needed to address the failure in ./specification/common/attribute-type-mapping.md.