Fix timestamp handling for the lastvalue aggregation

[dashpole]

Fixes #5510

From https://opentelemetry.io/docs/specs/otel/metrics/sdk/#metricreader:

The ending timestamp (i.e. TimeUnixNano) MUST always be equal to time the metric data point took effect, which is equal to when MetricReader.Collect was invoked. These rules apply to all metrics, not just those whose point kinds includes an aggregation temporality field.

Before #5305, we used the measurement time as the timestamp, but it didn't matter because the collection time is always the same as the measurement time for asynchronous instruments. We didn't catch the issue when we implemented synchronous instruments.

This PR changes the (end) timestamp handling for the Last Value aggregation to match the (end) timestamp handling for sum and histogram aggregations. As described in the spec above, we take the timestamp when computing the aggregation during Collect.

@MrAlias @juliusv

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.8%. Comparing base (ffe855d) to head (d822f09).

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #5517   +/-   ##
=====================================
  Coverage   84.8%   84.8%           
=====================================
  Files        269     269           
  Lines      18088   18091    +3     
=====================================
+ Hits       15341   15344    +3     
  Misses      2421    2421           
  Partials     326     326           

Files	Coverage Δ
sdk/metric/internal/aggregate/lastvalue.go	100.0% <100.0%> (ø)

... and 2 files with indirect coverage changes

[juliusv]

I don't know the codebase, but looks plausible, thanks :) 👍