feat: Hide MetricReader and friends

[cijothomas]

Option2 from #2917

Trimming public API, by hiding MetricReader+friends under feature flag. This won't affect normal usage of Metrics, but only custom MetricReader authors. It is unclear what scenario requires custom MetricReaders.....
Ability to write custom Exporter is still maintained.
Also removed Aggregation enum to existing View feature, as that was the only use for Aggregation.

Hoping to trim the questionable public API before declaring Metrics SDK as stable.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.3%. Comparing base (64cf291) to head (76cb13d).
Report is 1 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #2928   +/-   ##
=====================================
  Coverage   81.3%   81.3%           
=====================================
  Files        126     126           
  Lines      24254   24254           
=====================================
  Hits       19736   19736           
  Misses      4518    4518           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fraillt]

I have looked a bit deeper into this and here's my understanding (maybe not correct :)) about the situation.
If we ignore code for a bit and look philosophically, the purpose of Metrics SDK is to allow a user to specify how and when metrics should be exported.
How - is solved by PushMetricExporter.
When - is solved by MetricReader.
The how part is done nicely: it has export, temporality and few more to deal with technical stuff ("flush" and "shutdown").
The when part looks a bit more complex (for my taste at least) than it should be.
Ideally, user should accept some sort of CollectTrigger instance and provide implementation which would call fn collect(&mut self) either in the loop (for PeriodicReader) or some other way (e.g. pull based reader for Prometheus).

So if we could achieve something similar in #2917 , then probably we could stabilize this in Metrics SDK :)

P.S. maybe we should think about naming for PushMetricExporter and MetricReader interfaces before stabilization as well?
I would suggest to rename PushMetricExporter to MetricExporter (because Push part is actually controlled by collector), and would rename MetricReader to MetricCollector.

[cijothomas]

I have looked a bit deeper into this and here's my understanding (maybe not correct :)) about the situation. If we ignore code for a bit and look philosophically, the purpose of Metrics SDK is to allow a user to specify how and when metrics should be exported. How - is solved by PushMetricExporter. When - is solved by MetricReader. The how part is done nicely: it has export, temporality and few more to deal with technical stuff ("flush" and "shutdown"). The when part looks a bit more complex (for my taste at least) than it should be. Ideally, user should accept some sort of CollectTrigger instance and provide implementation which would call fn collect(&mut self) either in the loop (for PeriodicReader) or some other way (e.g. pull based reader for Prometheus).

Yes, Users should be in control of export interval - #2928 (comment)
i.e, they can control how often collect/export should get triggered automatically.
Additionally, users can trigger export/collect ad-hoc too, by invoking meter_provider.flush() themselves.
Most users don't need to even know that there is a thing/concept called MetricReader at all.

[cijothomas]

I would suggest to rename PushMetricExporter to MetricExporter (because Push part is actually controlled by collector), and would rename MetricReader to MetricCollector.

Agree with removing "Push" from MetricExporter.
The other one - not so sure. Spec calls it MetricReader. But Reader is being proposed to be hidden from end-users via feature flag in this PR, so we can alter it later too.

[utpilla]

Suggested change

	- *Breaking* change, affecting custom MetricReader authors: The
	- *Breaking* change, affecting custom `MetricReader` authors: The

[utpilla]

This PR link is added twice.

[utpilla]

We should probably just delete manual_reader.rs file instead of providing it under a feature. There doesn't seem to be any use case for it.

[utpilla]

Left some suggestions.