WIP: fix counter resets when merging batches

[fionaliao]

What this PR does

When merging samples from different iterators, histogram counter reset hints need to be recalculated. The mergeIterator currently does not do so.

This is currently a WIP to test out a possible fix.

We know the following:

• The chunks in each newNonOverlappingIterator within the mergeIterator don't overlap.
• The counter reset headers for the chunks in a single newNonOverlappingIterator are correct because a) the chunks don't overlap, and b) the first sample in each chunk has unknown hint due to Always return unknown hint for first sample in non-gauge histogram chunk prometheus/prometheus#15343.
• When merging a new batch into the batchStream, if the samples of the batch overlap, the samples must be overlapping with samples from another newNonOverlappingIterator. It cannot overlap with samples from the same newNonOverlappingIterator. If there is overlaps between iterators, we must set UnknownCounterReset.

The fix has two parts:

1. When merging, keep track of if the last sample was written from the current batchStream or the new batch. If we switch between them, write unknown, otherwise keep the current hint.
2. The above will always set the first sample in an incoming batch to unknown in merge(). However, a batch contains some consecutive samples in a chunk. A later batch might come from the same chunk and the samples could be consecutive to the previous batch's samples. Therefore, in batchStream, we keep a map of iteratorID -> last histogram timestamp from the iterator that was written to the batchStream. When we write the first sample in the new batch, we check if the previous sample in the batchStream has the same timestamp as the last histogram timestamp from the same iterator. If so, we can trust the counter reset hint for the sample in the new batch rather than resetting it. The idea for figuring out consecutive samples between batches using the previous timestamp comes from @krajorama and this PR of this: fix(histograms): inflated counter resets on merge #9823.

Note we could still be overdetecting unknown counter resets - it's possible that chunks in different newNonOverlappingIterators are actually consecutive but for now if samples are coming from different iterators we set them to unknown. This is because we don't know for sure as we don't have a way to tell if chunk are consecutive to each other at this point in the Mimir code (see prometheus/prometheus#15346 for related discussion).

Current TODOs:

• Go through code carefully, the reasoning for what is safe/correct to do gets tricky
• Add a bunch of tests

Which issue(s) this PR fixes or relates to

Fixes #

Checklist

• Tests updated.
• Documentation added.
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX].
• about-versioning.md updated with experimental features.