The metric sdk spec is looking to move to mixed status, with exemplars marked as "Feature-freeze". Without being marked as stable, I think we should take some precautions in the public API we expose related to exemplars.

Exemplars show up in just one place in our API: we allow ExemplarFilter to be registered with SdkMeterProviderBuilder#setExemplarFilter(ExemplarFilter). As discussed in #2421, this configuration is actually explicitly stated anywhere.

The other exemplar component is ExemplarReservoir. The spec says that reservoirs can be optionally specified via views, but we don't actually allow this. This means that users are stuck with the default reservoir strategy, and in particular, the default reservoir size which is based on the the number of available CPUs.

Some thoughts:

• Are we sure SdkMeterProvider is the right place for ExemplarFilter to be configured? I think probably yes.
• Do we want to allow custom implementations of ExemplarFilter, or only allow the three defaults (none, all, with_sampled_trace)? If not, we can adjust it to being an empty interface with internal implementations. I think its probably wise to disallow custom implementations for now.
• Should we keep ExemplarReservoir a public interface? I think no, since there is no ability to configure ExemplarReservoir anywhere in the API.