metricstarttimeprocessor: Copy true reset strategy from prometheus receiver

[dashpole]

Description

Copy the "metric adjuster" from the prometheus receiver to a new "true_reset_point" strategy in the metricstarttimeprocessor

Link to tracking issue

Part of #37186

Testing

Copied unit tests

Documentation

Updated the README.

Notes for reviewers

• I would recommend reviewing commit-by-commit. The first commit is copied verbatim, with minimal changes other than splitting into multiple files.
• I changed the function signature of AdjustMetrics to match the processMetrics function so that it doesn't need an additional wrapper layer.
• I removed the MetricsAdjuster interface, since it isn't needed (we implement the processor function for metrics now).
• I had to remove the validation of job + instance being present because it didn't pass generated tests. Regardless, we should not rely on those in a generic processor.

[dashpole]

cc @ridwanmsharif @jmacd @ArthurSens

[ridwanmsharif]

What are other strategies that you envision this processor supporting? using another metric's value for the start time (process_start_time_seconds)? Wouldn't those also need to use the true_reset_point strategy to deal with resets?

[dashpole]

If a metric's value resets, it seems like we should always reset the start time, but I don't think that should involve inserting a "true reset" point. I think it should be implicit for all adjustment strategies (maybe with an on/off config option, similar to fallback to collector start time?).