feat(query-ocherator): QueryCache - improve usage of in-memory cache

[ovr]

Fixing a broken logic, which doesn't allow us to cache short refresh keys in memory. Due to this bug, instead of caching keys with short life time in QueryQueue's in-memory cache, we get keys from Cache Store. It's fast, 1-3 ms for key lookup, but there is no reason to do that.

I don't want to spend a lot of time on benchmarking. I did a simple benchmark, 10 runs, the fastest I've uploaded. It's just a simple query with 1 measure and 1 dimension, which queries a cube with a 5-minute refresh key and pre-agg with build_range.

before

  █ TOTAL RESULTS 

    checks_total.......................: 7890    763.045245/s
    checks_succeeded...................: 100.00% 7890 out of 7890
    checks_failed......................: 0.00%   0 out of 7890

    ✓ status is 200
    ✓ response time < 1000ms
    ✓ has data

    HTTP
    http_req_duration.......................................................: avg=200.53ms min=9.65ms  med=200.38ms max=493.66ms p(90)=345.91ms p(95)=369.93ms
      { expected_response:true }............................................: avg=200.53ms min=9.65ms  med=200.38ms max=493.66ms p(90)=345.91ms p(95)=369.93ms
    http_req_failed.........................................................: 0.00%  0 out of 2630
    http_reqs...............................................................: 2630   254.348415/s

    EXECUTION
    iteration_duration......................................................: avg=201.36ms min=10.23ms med=201.16ms max=494.43ms p(90)=346.58ms p(95)=370.53ms
    iterations..............................................................: 2630   254.348415/s
    vus.....................................................................: 99     min=10        max=99 
    vus_max.................................................................: 100    min=100       max=100

    NETWORK
    data_received...........................................................: 128 MB 12 MB/s
    data_sent...............................................................: 1.1 MB 103 kB/s

after

  █ TOTAL RESULTS 

    checks_total.......................: 8211    797.606191/s
    checks_succeeded...................: 100.00% 8211 out of 8211
    checks_failed......................: 0.00%   0 out of 8211

    ✓ status is 200
    ✓ response time < 1000ms
    ✓ has data

    HTTP
    http_req_duration.......................................................: avg=187.89ms min=9.42ms  med=182.97ms max=462.07ms p(90)=324.5ms  p(95)=342.61ms
      { expected_response:true }............................................: avg=187.89ms min=9.42ms  med=182.97ms max=462.07ms p(90)=324.5ms  p(95)=342.61ms
    http_req_failed.........................................................: 0.00%  0 out of 2737
    http_reqs...............................................................: 2737   265.86873/s

    EXECUTION
    iteration_duration......................................................: avg=188.59ms min=10.09ms med=183.46ms max=464.71ms p(90)=325.95ms p(95)=344.19ms
    iterations..............................................................: 2737   265.86873/s
    vus.....................................................................: 99     min=10        max=99 
    vus_max.................................................................: 100    min=100       max=100

    NETWORK
    data_received...........................................................: 134 MB 13 MB/s
    data_sent...............................................................: 1.1 MB 107 kB/s
    data_sent...............................................................: 1.1 MB 107 kB/s