Add timestamp to scope_info and target_info GMP metrics

[damemi]

Fixes #584

[dashpole]

I think it is reasonable to fix it this way for now, and we should try to make sure we get this fixed upstream ASAP, since it produces errors when using the GMP exporter. We should make an issue to track a solution to the problems this creates below:

It is possible that the collector will be exporting a batch of metrics that are old (e.g. if metrics have been persisted to disk for an hour from on-prem before sending if there was a network outage). In that case, the timestamp of the target_info metric would be now() but the timestamp on the metrics would be an hour ago, which is odd. It could also cause the timestamps of multiple batches to be very close together if, for example, i'm backfilling historical data sequentially. In that case, the timestamps of my regular metrics would be far apart (because they were collected at regular intervals), but if they are uploaded quickly, I would get a bunch of target_info and scope_info metrics that are really close together in time, and could cause write errors.

The solution adopted by the PRW exporter is to use the most recent timestamp in the metrics contained within the resource/scope.

[codecov]

Codecov Report

Merging #585 (61a5514) into main (e22e262) will decrease coverage by 0.57%.
The diff coverage is 39.39%.

@@            Coverage Diff             @@
##             main     #585      +/-   ##
==========================================
- Coverage   64.09%   63.52%   -0.57%     
==========================================
  Files          38       38              
  Lines        4347     4400      +53     
==========================================
+ Hits         2786     2795       +9     
- Misses       1443     1483      +40     
- Partials      118      122       +4     

Impacted Files	Coverage Δ
...collector/googlemanagedprometheus/extra_metrics.go	71.63% <34.42%> (-28.37%)	⬇️
...tor/integrationtest/testcases/testcases_metrics.go	100.00% <100.00%> (ø)
...lector/internal/datapointstorage/datapointcache.go	80.30% <0.00%> (-3.04%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[damemi]

@dashpole no I agree doing it right makes sense now. should we revert the broken release or just publish the new one asap?

[dashpole]

nice. Didn't think the fix would be that quick

[dashpole]

feel free to merge with coverage checks failing.