feat(cache): Add Cache-Control: no-cache support for Loki instant queries.

[kavirajk]

What this PR does / why we need it:
Goal is, if header Cache-Control: no-cache is set, we guarantee that response user got for that query is never from the results cache.

Two changes at high-level

1. Loki: Queryfrontend interprets Cache-Control header and bypass the results if the value is no-cache.
2. LogCLI: Add extra flag --nocache to support setting the right header when sending queries to Loki.

Changes in Action:

1. Normal case using results cache.

-bash-5.2$ ./cmd/logcli/logcli instant-query 'sum(rate({job="varlogs"}[3h]))' -q
[
  {
    "metric": {},
    "value": [
      1715602199.729,
      "0.035555555555555556"
    ]
  }

Hitting the results cache from the following log lines in Loki

cache_result_req=17 cache_result_hit=16

2. Using HTTP header to bypass results caching

-bash-5.2$ ./cmd/logcli/logcli instant-query 'sum(rate({job="varlogs"}[3h]))' --nocache -q
[
  {
    "metric": {},
    "value": [
      1715602387.564,
      "0.035555555555555556"
    ]
  }

Not hitting the results cache from the following logs in Loki

cache_result_req=0 cache_result_hit=0

Which issue(s) this PR fixes:
Fixes NA

Special notes for your reviewer:

1. This PR adds support only for instant queries now. Follow up PRs will support for all types of queries.

2. Instant queries uses downstream engine via split_by_range middleware. Which converts LokiInstantRequest to Params and convert back from Params to LokiInstantRequest. So added support to persist cachingOptions in params as well.

3. Since this header is only valuable for Query-frontend, we don't persist this header when passing the subqueries to the querier (via HTTP -> GRPC -> HTTP roundtrip).

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• For Helm chart changes bump the Helm chart version in production/helm/loki/Chart.yaml and update production/helm/loki/CHANGELOG.md and production/helm/loki/README.md. Example PR
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[ashwanthgoli]

lgtm. just a couple of nits

[ashwanthgoli]

should we change this shouldCacheReq to shouldLookupCache or bypassCache?
the current name is a bit confusing, it reads "whether this request should be cached"?

[kavirajk]

Agree. I can change it in my tests. But the original type still called ShouldCacheReq (IMO, still confusing, because the same request's results can still be cached after getting it from the upstream).

Should ideally be called something like ShouldLookupCache. I will fix the naming on my test now. Renaming the original type I can do it in separate PR may be.

[ashwanthgoli]

this could be flaky at times, because the extent might end up in the previous day when this test runs on a day boundary

[ashwanthgoli]

we could use constant time range similar to other tests to keep this predictable? mkExtent(50, 120)

[kavirajk]

extent should be irrelevent here I think because, the test is make sure we are calling upstream next handler instead of looking up in the cache in the first place (independent of cache hit or cache miss).

But good idea to make it constant anyway. Will update it.