(internal/global): Global registration mechanism does not check for nil objects

[jmacd]

Description

In #5881, there was discussion about the appearance of a possible panic in the internal/global meter package. If we intend to avoid every possibility of a panic due to a misbehaving SDK, then there are other code paths we should look at fixing.

I thought I would document one of these.

Steps To Reproduce

Create an alternate metric SDK, as in the file alternate_meter_test.go from #5881. Have the SDK return nil from any one of its instrument constructors. The internal/global package has (14 cases, presently) code like:

	ctr, err := m.Float64ObservableCounter(i.name, i.opts...)
	if err != nil {
		GetErrorHandler().Handle(err)
		return
	}
	i.delegate.Store(ctr)

The problem is that ctr can be nil if the SDK misbehaves because the atomic.Value.Store() method immediately panics.

	if val == nil {
		panic("sync/atomic: store of nil value into Value")
	}

Expected behavior

If this is an unacceptable risk, then we should add tests for these 14 cases. If we agree that a misbehaving SDK is responsible for itself, and if the user installs one of those as a global, it's OK to crash, then we can put a note in the code and close this issue.

[Bla5e]

Wow c'est impressionnant