rhythm: fix block time range adjustment

[javiermolinar]

What this PR does:
This fixes the previous behavior, where the end date was always set to the start time. This was a translation of our behavior in the ingesters, where the start and end dates are set to now() if they are outside the time range.

How it works now:
It checks independently the start and the end.
If the end is before the start it will set it to the start
If the end is after the end range it will set it to the end range

Checklist

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

[mapno]

This is just wrong data, no? I don't think we have to fix it, or at least it's not related to ingestion slack.

[mapno]

Did you mean end.Before(startOfRange) instead?

Suggested change

	if end.Before(start) {
	warn = true
	end = start
	}
	if end.Before(startOfRange) {
	warn = true
	end = start
	}

[javiermolinar]

Not wrong data, old data. Imagine someone wants to add old spans into Tempo
I did a very similar fix a time ago:
#3954
We need to correct the end date or the block will be wrong

[javiermolinar]

using start instead of startOfRange makes sense to me because it addresses both scenarios. If the start is before the startOfRange it has been already adjusted. In the edge case where end < startOfRange < start it fixes it as well

[mapno]

In the edge case where end < startOfRange < start it fixes it as well

This is what I meant by wrong data, end < start is logically incorrect.

[mdisibio]

Internally during a test block builders flushed several blocks in a row with meta.start==meta.end. I'm not sure that this change is the fix, because the only related change is the case end after endOfRange. Previously it was set to start and now it's endOfRange. For this to be the issue it would have to mean that every trace in the block was a long-running one that exceeds the buffer s.startTime.Add(s.slackDuration + s.cycleDuration). I'd like to dig more and see if there is another explanation.

[mapno]

LGTM. I think end.Before(start) is safe but feels a bit strange.

[mapno]

In the edge case where end < startOfRange < start it fixes it as well

This is what I meant by wrong data, end < start is logically incorrect.