query-frontend: stop using creation_grace_period to limit query length

[dimitarvdimitrov]

What this PR does

Reviewing #7496 made me realize this.

#3144's reason for truncating queries is to not fill the scheduler queue with effectively useless queries. Some queries can legitimately be querying into the future without there being samples ingested for that time. For example predict_linear used on a longer term scale.

Since the impact of undoing this change in this PR is per-tenant I think it is reasonable - it will only impact the tenant sending the large queries. Perhaps worth noting that -query-frontend.max-total-query-length still applies.

Which issue(s) this PR fixes or relates to

Fixes #5445

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.

[dimitarvdimitrov]

cc @hi-rustin @pracucci @colega since you were involved in the original work

[pracucci]

I'm not convinced removing it, sorry. IIRC, this protection was introduced after an incident and now we're removing that protection. Maybe we can convert it into a new dedicated limit, which is more generous (e.g. 1 day ahead is fine, 100 years ahead is not).

[dimitarvdimitrov]

e.g. 1 day ahead is fine, 100 years ahead is not

we still have max-total-query-length which would reject a 100 year query. Why is a query into the future different from a query into the past? The former is much cheaper.

IIRC, this protection was introduced after an incident and now we're removing that protection

I couldn't find the problem this caused. I think you just noticed it happening, but the actual problem was related to mmap and lazy loading.

[colega]

I agree with @dimitarvdimitrov's arguments: querying into the future should be cheaper than querying into the past, and still limited by the max query length.

[pracucci]

Ok, your arguments make sense.