Improve efficiency of ETW metrics exporter

[mattbodd]

Fixes #104
Design Decisions:

• Follow .Net and C++ implementations and use helper methods to serialize fragments of metric points into a coherent, exportable buffer
• Construct a new ResourceMetrics for each metric point and serialize each into an exportable buffer

Changes

Please provide a brief description of the changes here.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

Attention: Patch coverage is 75.42373% with 29 lines in your changes missing coverage. Please review.

Project coverage is 53.9%. Comparing base (72a6d4b) to head (47a941d).

Files with missing lines	Patch %	Lines
opentelemetry-etw-metrics/src/exporter/mod.rs	75.4%	29 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main    #134     +/-   ##
=======================================
- Coverage   54.1%   53.9%   -0.2%     
=======================================
  Files         42      42             
  Lines       6279    6149    -130     
=======================================
- Hits        3397    3316     -81     
+ Misses      2882    2833     -49     

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

[mattbodd]

Comparing the latest exporter benchmark results between the proposed export implementation and the previous export implementation, there is a ~26% improvement.

[mattbodd]

Comparing the latest exporter benchmark results between the proposed export implementation and the previous export implementation, there is a ~26% improvement.

With a more realistic ResourceMetrics, the improvement looks to be closer to 38%

[psandana]

We noticed some tonic namespace usage along with types with Tonic prefix. Discussing with @cijothomas we got clarified OpenTelemetry is not using Tonic, they are just types coming from proto definitions.

Thus, this comment is not blocking as the change is unrelated to this PR, but we propose making those proto types more generic, thus we prevent future confusions regarding tonic usage or not.

[mattbodd]

We noticed some tonic namespace usage along with types with Tonic prefix. Discussing with @cijothomas we got clarified OpenTelemetry is not using Tonic, they are just types coming from proto definitions.

Thus, this comment is not blocking as the change is unrelated to this PR, but we propose making those proto types more generic, thus we prevent future confusions regarding tonic usage or not.

I borrowed the use pattern set in open-telemetry/opentelemetry-rust/opentelemetry-proto/src/transform/metrics.rs. @psandana or @cijothomas do you have suggestions for better generic names?

[utpilla]

Not a blocker for this PR but we should be able to reuse the vec instead of allocating a new one for each export. MetricExporter struct can hold a vec as one of its fields and keeping using that vec for each export.

[mattbodd]

@utpilla good call out. I'll leave that work to a future PR if that's ok with everyone

[mattbodd]

I make a tweak that's part of the way towards this improvement. Now emit_export_metric_service_request takes a &mut Vec<u8> as a parameter to avoid allocating a fresh Vec<u8> every invocation. Now a new vector is only initialized once per export.

[utpilla]

It might be better to micro benchmark just the serialization and export of one data point instead of 20000. It would keep the calculations simple when comparing two benchmark results.

[lalitb]

I think this is coming from - #134 (comment)