Disable chunk trimming in Receivers

[fpetkovski]

This change is motivated by the following Slack discussion: https://cloud-native.slack.com/archives/C02KR205UMU/p1728575718863519

When trimming is not disabled, receivers end up recoding all chunks
in order to drop samples that are outside of the range.
This ends up being very expensive and causes ingestion problems during high
query load.

Trimming will be triggered in the following case:

|-------------| chunk
   |-------|        requested range

This commit disables trimming which should reduce CPU usage in receivers.
The engine already skips samples outside of the query range, so correctness will not be affected.

• I added CHANGELOG entry for this change.
• Change is not relevant to the end user.

Changes

Verification

[fpetkovski]

Actually both engines will skip samples outside of the range, so we should be safe here. Technically we don't really trim chunks from Store Gateway so the same idea applies there.

[fpetkovski]

Forgot to sign DCO and had to force-push.

[pedro-stanaka]

Do we need changelog for this one?

[bwplotka]

Let's double check we are explicitly stating that in Series gRPC API too (that time matcher is "best-effort" to some extend).

I think we already do that in sidecars

[fpetkovski]

I've extended the godoc on the Series RPC to mention that chunks don't need to be within the exact range. I think this is good enough for now and we don't need a changelog entry because the change is not user facing.

[yeya24]

@fpetkovski Is there a user facing behavior change if we do this? Does it change any of the query results?
Just want to understand if we need a changelog or not.

Actually both engines will skip samples outside of the range, so we should be safe here. Technically we don't really trim chunks from Store Gateway so the same idea applies there.

From this comment I guess there is no user facing changes if we change it?

[fpetkovski]

The engine will discard samples outside of the query range, so results are not affected in any way. IMO a changelog entry should not be needed for Thanos users, but we can add one if you still think it is necessary.

[yeya24]

@fpetkovski Thanks. If there is no user facing change then let's skip the changelog.
I am wondering if we have any test to capture that this doesn't impact the correctness. Hopefully we don't have any edge case of that.

[fpetkovski]

@MichaHoffmann pointed me to the acceptance tests we run from the Prometheus repo itself: https://github.com/thanos-io/thanos/blob/main/pkg/query/query_test.go#L53.

So I think we should be good. Also store-gw has the same behavior which I think hasn't shown any problems so far.