Move main graph to new API v2 endpoint

[RobertJoonas]

Changes

• Implement the required API v2 logic to support everything that main-graph needs
• A major rewrite of main_graph_test.exs - populate_stats and other tests setup remained the same, but the request is now made against the new endpoint and the assertions on the returned data structures have changed significantly.
• When include.time_labels is set, also include meta.time_label_result_indices (right next to meta.time_labels themselves). This helps to avoid searching for rows corresponding to a time label on the client side.
• Support returning comparisons in the API v2 response format. This was tricky to figure out. See below for details.
• Fix a known bug in API v2 (see commit with description 4923839)
• Remove the main graph endpoint
• Remove comparisons logic from legacy timeseries (see commit with description 7ad120a)
• Wire up the UI properly
• Update changelog

New comparison response format for timeseries

Unlike comparisons with empty dimensions or non-time dimensions, the number of dimension groups returned for a time dimension query is not guaranteed to match between original and comparison results. The simplest example: a custom period comparison.

In order for the response to indicate which original group corresponds to which comparison group, we had two options:

1. Stick with the current response structure where a comparison map is merged into each row of results

This was the initial solution that this PR tried to implement. The reason this approach seemed better was keeping a single response structure of comparisons. For non-time dimension queries, this format makes perfect sense and is easy to read.

However, the following cons have contributed to choosing option 2 instead:

• Need to zip results and comparison_results padding the shorter result set with nils if necessary.
• Unlike in a regular (without comparisons) timeseries response, construct rows with empty metrics in both lists where necessary. This is because ClickHouse does not return time buckets that didn't have any data in them.
• Both of the above contribute to a heavier payload
• The main-graph component would have to implement 2 different ways of rendering the graph - iterating over meta.time_labels (when not comparing) and iterating over results (when comparing)

2. Return comparison_results as a separate response field when a time dimension is involved

Even though a separate form of returning comparisons seems inconsistent , it makes much more sense for comparison results to be separated in timeseries as it alleviates all the cons mentioned in option 1.

Tests

• Automated tests have been added

Changelog

• Needs a changelog update

Documentation

• This change does not need a documentation update

Dark mode

• This PR does not change the UI