perf(query): reduce regex query fanout

[alextheimer]

Pull Request checklist

• The commit(s) message(s) follows the contribution guidelines ?
• Tests for the changes have been added (for bug fixes / features) ?
• Docs have been added / updated (for bug fixes / features) ?

Currently, the ShardKeyRegexPlanner asks its inner planner to create an ExecPlan for each one of a LogicalPlan's shard keys. This is inefficient; if 100 shard keys are matched but all data lies on only two partitions, it would be much more efficient to instead ask the inner planner to materialize one plan per partition.

This PR materializes ExecPlans in this more-efficient manner. The ShardKeyRegexPlanner now passes LogicalPlans with original regex filters to lower-level planners. The MultiPartitionPlanner now has infrastructure added to resolve shard-keys and determine the partitions to be queried; it now materializes plans per-partition (instead of per-shard-key). Again, regex is passed to lower-level planners; the SingleClusterPlanner now also has the infrastructure to materialize regex-filtered plans.

[vishramachandran]

@alextheimer Query Stats need to be keyed with "multiple-ns" for the namespace field for NS-Regex queries within partition.

[alextheimer]

@vishramachandran it looks like the latest develop has this covered (I've rebased the PR):

• In TimeSeriesShard:

  FiloDB/core/src/main/scala/filodb.core/memstore/TimeSeriesShard.scala

  Line 1936 in 6cb5433

  val metricGroupBy = deploymentPartitionName +: clusterType +: shardKeyValuesFromFilter(metricShardKeys, filters)

• In DownsampledTimeSeriesShard:

  FiloDB/core/src/main/scala/filodb.core/downsample/DownsampledTimeSeriesShard.scala

  Line 355 in 6cb5433

  val metricGroupBy = deploymentPartitionName +: clusterType +: metricShardKeys.map { col =>

QueryStats are also updated in e.g. label-value iterators, but I'll leave those keys alone since they aren't related to PromQL queries.

[amolnayak311]

Why comment out the test?

[alextheimer]

I was hoping others would know what this test was for-- it looks like we used to expect partition-split plans would always return at least one data-point per partition, regardless of lookback/offset. That doesn't jive with the way we handle partition-splits elsewhere in the planners, so I think this test should be removed.

The reason it passed prior to this PR is because the MPP sent PeriodicSeries and RawSeries through the old materializePeriodicAndRawSeries logic. That always materialized at least one plan per partition.

materializePeriodicAndRawSeries was built to materialize plans with equality-only filters, so that would not work for this PR. Instead, plans are:

• if split, passed to the regex-handling materializeSplitLeafPlan, which accounts correctly for lookback.
• if not split, forwarded as-is to any partitions that own the query data.