Metrics: MetricPointValueStorage explicit layout struct

[CodeBlanch]

Changes

Added MetricPointValueStorage to store the values needed by MetricPoint. MetricPointValueStorage is basically a union where the same bytes are used for either long or double modes.

Details

Before we had 3 longs & 3 doubles (48 bytes) for all MetricPoints and then an additional 16 bytes (long Count + double Sum) for histograms. This should give us a fixed 32 bytes for all types of MetricPoints.

I also tried to improve the clarity of the code by renaming things from "val"/"value" style to "current"/"snapshot" style.

[codecov]

Codecov Report

Merging #2694 (401898d) into main (580a2a5) will increase coverage by 0.03%.
The diff coverage is 88.37%.

@@            Coverage Diff             @@
##             main    #2694      +/-   ##
==========================================
+ Coverage   82.88%   82.92%   +0.03%     
==========================================
  Files         249      249              
  Lines        8708     8704       -4     
==========================================
  Hits         7218     7218              
+ Misses       1490     1486       -4     

Impacted Files	Coverage Δ
src/OpenTelemetry/Metrics/HistogramBuckets.cs	100.00% <ø> (ø)
src/OpenTelemetry/Metrics/MetricPoint.cs	85.00% <88.37%> (-0.49%)	⬇️
...nTelemetry/Internal/OpenTelemetrySdkEventSource.cs	74.76% <0.00%> (+2.80%)	⬆️
...ZPages/Implementation/ZPagesExporterEventSource.cs	62.50% <0.00%> (+6.25%)	⬆️

[utpilla]

secondaryValue.Snapshot used for Histogram sum is only used by Histogram types. Should we move it to HistogramBuckets instead? (Add another struct explicitly laid out for a single long or double field?) Currently, we will assign 8 bytes of memory taken up this for all types of MetricPoint.

[CodeBlanch]

@utpilla I'm not opposed to that. For counters & gauges, there is a null pointer to HistogramBuckets on the MetricPoint struct. Even though it is null, those structs still have to pay for the storage of the pointer. I think it is sizeof(IntPtr) which is 4 bytes on 32bit and 8 bytes on 64bit. Not 100% sure about that. If we could use those 8 bytes we're holding for the pointer for the "lastValue" delta stuff (and move the sum tracking completely into HistogramBuckets) we could save another 16 bytes for all counters & gauges (eliminate secondardValue, basically). I was going to mess with that, but feel free to give it a shot.