Support for multiple dimensions for report calling (similar to GA4)

[nahiyan-yasaar-selise]

We noticed that metric blocks, charts and the WF report node all utilize the /report? query, so this is relevant to that. It seems even if we add more dimensions to the call, the system ignores it and forces it to be a single dimension dimension_0. We would like support for multiple dimensions as it is useful in many reporting situations.

Case 1: Charts with two Y-axes.
There are many cases where a chart has two y-axes, one to the left (e.g. representing monetary values) and one to the right (e.g. representing count), so support for at least two dimensions would be very useful to avoid creation of separate charts for values and counts having the same filters. So basically, the reporting call should support arbitrary number of dimensions but the chart builder front end would be limited to having support for two dimensions.

For an idea of enabling arbitrary dimensions in charts see this idea.

Moreover, since the dimensions for these two axes (values and counts) are the same (e.g. Account Managers), the builder should allow multiple dimensions to reference the same field instead of removing it from being an option when selecting the field to be referenced.

To avoid possible user confusion upon hovering on the graph, the secondary axes values can be set to be bordered and/or striped (if bar/sector) or dotted/dashed (if line) or hollow dot/circle (if point).

Case 2: Reporting via WF
There are cases where reports are generated as an HTML table by first making a report call and then feeding the resulting array of KVs into a JSEnv node because it is the most performant approach as opposed to nested WF loops. Without support for multiple dimensions we are forced to keep a separate field that concatenates every possible dimensional grouping and have this field as dimension_0 in the calling. This is then split up inside JSEnv.

While more performant than the regular approach, it isn't scalable because new requirements might need more (dimension) fields and it isn't possible to add those values to historical data retroactively without running an update of them. Plus, the JSEnv also needs to loop through records unnecessarily if particular dimensions aren't needed for record splitting. For example, if DimConcat field is like dim1|dim2|dim3 and we only need to split data by dim2 and dim3 for a specific use case, we would still get data split based on dim1 as well which adds unnecessary loops.

This way, support for multiple dimensions similar to GA4 reporting API would be very useful.