Add query results cache support for cardinality analysis API

[pracucci]

What this PR does

We're seeing some customers issuing the same cardinality analysis query over and over, few seconds apart from each other (likely coming from a script or internal tooling, given the user agent). These requests can be pretty heavy for the ingester, in terms of CPU utilization and memory allocations.

The cardinality analysis API, whose returned value is already a close-to-reality approximation today (but not a 100% accurate count), doesn't need to guarantee read-after-write and some short cache TTL could be applied to it. After discussing it with few people at Grafana Labs, in this PR I'm introducing the optional support to cache cardinality query results (disabled by default, TTL configurable on a per-tenant basis).

Note to reviewers:

• dskit has been updated to get a couple of more methods to cache.InstrumentedCacheMock (PR)
• I manually tested it and looks doing its job

Which issue(s) this PR fixes or relates to

N/A

Checklist

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

[pstibrany]

Looks good, nice work!

[pracucci]

Thanks @pstibrany for your review. I should have addressed all your comments and the TODO that I left when you did the 1st review. There are two things I would prefer to do in follow up PRs:

1. Improve HTTP API doc (since will require docs squad review, I prefer to not block this PR)
2. Try to improve metrics we have to compute the query results cache hit ratio (right now we can't distinguish between range and cardinality queries, but this will impact dashboard too, so I prefer to keep it separated)

[pstibrany]

Looks good, thank you!