[OTLP] Cache metric metadata bytes for protobuf serializer

[unsafePtr]

Follow-up to #7303 which applied the same pattern to the resource bytes.

Changes

Caches the protobuf-encoded bytes of Metric.Name / Description / Unit keyed by Metric instance, replayed on every export via Buffer.BlockCopy. These three fields are set at instrument creation and immutable for the lifetime of a Metric, so the bytes never change after first computation.

Implementation mirrors ProtobufOtlpResourceSerializer:

• ConcurrentDictionary<Metric, byte[]> static cache.
• ArrayPool<byte>-backed scratch buffer with grow-on-overflow retry for the one-shot slow path.
• Fast path: single GetOrAdd + Buffer.BlockCopy.

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated — existing round-trip tests in OtlpMetricsExporterTests and ProtobufOtlpMetricSerializerTests cover the new path.
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable) — no public API changes.

[martincostello]

Would be good to see some before/after numbers before merge.

[cijothomas]

Need to see if this "leaks" Metric.

Unlike Resource (effectively a per-provider singleton), Metric instances come and go. A static ConcurrentDictionary<Metric, byte[]> pins every Metric it ever sees for the process lifetime, leaking memory for apps.

See if this makes sense and see if we can do alternates like ConditionalWeakTable<Metric, byte[]>, or an internal field on Metric itself.?

[unsafePtr]

Benchmark results for the metric metadata cache.

BenchmarkDotNet v0.15.8, Windows 11 (10.0.26200.8457/25H2/2025Update/HudsonValley2)
13th Gen Intel Core i7-13700KF 3.40GHz, 1 CPU, 24 logical and 16 physical cores
.NET SDK 10.0.300
  [Host]     : .NET 10.0.8 (10.0.8, 10.0.826.23019), X64 RyuJIT x86-64-v3
  DefaultJob : .NET 10.0.8 (10.0.8, 10.0.826.23019), X64 RyuJIT x86-64-v3

Before (no cache)

Method	MetricCount	Mean	Error	StdDev	Allocated
WriteMetricsData	1	91.52 ns	0.395 ns	0.369 ns	-
WriteMetricsData	4	237.82 ns	0.559 ns	0.467 ns	-
WriteMetricsData	16	790.89 ns	5.556 ns	5.197 ns	-
WriteMetricsData	64	3,034.48 ns	25.901 ns	22.960 ns	-
WriteMetricsData	256	12,332.34 ns	198.683 ns	185.848 ns	-

After (with cache)

Method	MetricCount	Mean	Error	StdDev	Allocated
WriteMetricsData	1	73.79 ns	0.927 ns	0.822 ns	-
WriteMetricsData	4	175.44 ns	3.279 ns	3.903 ns	-
WriteMetricsData	16	596.32 ns	11.787 ns	18.351 ns	-
WriteMetricsData	64	2,229.27 ns	44.045 ns	50.722 ns	-
WriteMetricsData	256	9,260.80 ns	180.011 ns	274.896 ns	-

Delta

MetricCount	Δ Mean	Speedup	Per-metric saved
1	−17.73 ns	1.24×	~17.7 ns
4	−62.38 ns	1.36×	~15.6 ns
16	−194.57 ns	1.33×	~12.2 ns
64	−805.21 ns	1.36×	~12.6 ns
256	−3,071.54 ns	1.33×	~12.0 ns

Steady-state savings of ~12 ns per metric in the metadata write path. Zero allocations either way — the original serializer was already alloc-free; this PR cuts CPU work, not memory.

[unsafePtr]

@martincostello , @cijothomas generally I was expecting way smaller perf benefit here, comparing to Resource. If ~20ns win doesn't justify code changes, please feel free to close the PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.93%. Comparing base (ae672d0) to head (47a533c).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7307      +/-   ##
==========================================
- Coverage   89.94%   89.93%   -0.02%     
==========================================
  Files         276      276              
  Lines       14007    14032      +25     
==========================================
+ Hits        12599    12619      +20     
- Misses       1408     1413       +5     

Flag	Coverage Δ
unittests-Project-Experimental	89.87% <100.00%> (+<0.01%)	⬆️
unittests-Project-Stable	89.76% <100.00%> (-0.16%)	⬇️
unittests-Solution	89.80% <100.00%> (-0.12%)	⬇️
unittests-UnstableCoreLibraries-Experimental	47.19% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ntation/Serializer/ProtobufOtlpMetricSerializer.cs	99.01% <100.00%> (+0.07%)	⬆️
...ation/Serializer/ProtobufOtlpResourceSerializer.cs	85.71% <ø> (-0.34%)	⬇️
...ol/Implementation/Serializer/ProtobufSerializer.cs	91.89% <100.00%> (+0.30%)	⬆️

... and 3 files with indirect coverage changes

[unsafePtr]

Polyfill classes I took from PolySharp https://github.com/Sergio0694/PolySharp/blob/5f31620db9e843da564c5d911d5befd6dcfb4b0f/src/PolySharp.SourceGenerators/EmbeddedResources/RuntimeSupported/System.Diagnostics.CodeAnalysis.DynamicallyAccessedMembersAttribute.cs#L45

[martincostello]

This looks good to me so far. I defer to @cijothomas being happy regarding the lifetimes before sticking a ✅ on this PR though.

[unsafePtr]

Updated changes coming from #7326. Unified pattern under common GetOrAdd polyfill for ConditionalWeakTable