Consider query select time in max query length check

[yeya24]

What this PR does:

Right now, there is a check for max query length in the query frontend query range middleware. It only checks the start and end parameter of range query API and see if it exceeds a maximum time range.

However, this check doesn't analyze the query string itself. For example, up[60d]. The time window 60d can be very large and exceeds the limit. However, it is not checked at query frontend.

To fix this issue, there is another checkfor max query length at Querier right now, which happens per Select only and it considers the time range of the query itself. For example, up[60d] can be rejected at Querier if the limit is configured as 30d.

However, this solution isn't perfect because a query can have multiple selects. rate(up[25d]) + rate(up[25d] offset 25d) + rate(up[25] offset 50d) actually queries 75 days of data but each select only queries 25 day time range so it will be allowed.

To address this issue in a better way, additional check logic is added in Query Frontend to analyze the whole query and see the max time range it queries. With this check, the check at Querier can actually be turned off.

Overall changes:

1. Additional max query length check at Query Frontend Query Range Middleware
2. Added the same logic to Query Frontend Instant Query Middleware. Previously there is no max query length check for instant query
3. Added the same logic to Ruler. Previously Ruler relies on max query length at Querier level
4. Added a new flag querier.ignore-max-query-length to disable checking max query length at Querier.

Which issue(s) this PR fixes:
Fixes #

Checklist

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