Tests should use configured provider types for non-standard SDKs

[c24t]

Follow-up to #466.

Many ext tests use the default SDK TracerProvider and MeterProvider types. Some ext packages (typically "integrations") only rely on the API package, other ext packages (typically "exporters") rely on the SDK package because they use types defined in the API.

Both kinds of ext packages should work with the default no-op providers, built-in SDK providers, and custom SDK providers. Even though the SDK package needs to be present to use an exporter ext package, the user may configure their application with DefaultProvider from the API package. For this reason, the exporter shouldn't rely on SDK-specific implementation details.

To make sure we're not relying on the built-in SDK implementation, and to support writing custom SDKs, we should refactor ext tests to use each available provider. In general, custom SDKs should behave the same way as the built-in SDK, but we will want separate tests for API-provided providers.

[mauriciovasquezbernal]

Follow-up to #466.

Many ext tests use the default SDK TracerProvider and MeterProvider types. Some ext packages (typically "integrations") only rely on the API package, other ext packages (typically "exporters") rely on the SDK package because they use types defined in the API.

Do you mean exporters use types defined in the SDK?

Both kinds of ext packages should work with the default no-op providers, built-in SDK providers, and custom SDK providers. Even though the SDK package needs to be present to use an exporter ext package, the user may configure their application with DefaultProvider from the API package. For this reason, the exporter shouldn't rely on SDK-specific implementation details.

I totally agree for the integration packages, but I'm not sure what you mean for the exporters. As far as I know exporters are an SDK-only concept, so it's fine for them to rely on the SDK internal details. Exporters would not be even invoked if the user chooses the default no-op implementation, the application should work in that case. Could you please clarify?

[lzchen]

Discussed 12/18:

We need to setup tests in such a way where we test the instrumentations with the no-op providers.

1. Add to test-utils to instantiate default providers (no sdk components)
2. All tests that we write should test the no-op provider and the sdk provider.

This is specifically to ensure that nothing bad will happen if the default sdk is not used (instrumentations won't crash using only the no-op provider).