Allow sorting breakdown lists by some metrics

[apata]

Changes

• On the dashboard, allow Metrics (aka column configurations) to
  • specify width they need
  • specify if they are sortable
• Default sort order for breakdown endpoints is hardcoded on the dashboard (needed to show what column the report is sorted by)
• Unifies Google Keywords modal

Tests

• Automated tests have been added

Changelog

• Entry has been added to changelog

Documentation

• Docs update is not needed

Dark mode

• The UI has been tested both in dark and light mode

[github-actions]

Preview environment👷🏼‍♀️🏗️
PR-4513

[RobertJoonas]

Looks really good overall, and everything works nicely on staging. Good job! 🙌

We could make some things more consistent and explicit though. Comments inline.

[RobertJoonas]

It feels like we're somewhere in the middle of conversion_rate and group_conversion_rate here.

The breakdown reports (e.g. /sources, /browsers, etc...) are returning the metric under the conversion_rate key in the API response. And yet the frontend sends order_by as ["group_conversion_rate", "desc"].

We should fix this discrepancy. The new API considers them two different metrics, so we should make the breakdown actions (such as Api.StatsController.sources) explicitly ask for the conversion rate that makes sense in that report context.

So sources, browsers, pages, etc, would directly ask for group_conversion_rate from the lower level Breakdown module (rather than let it transform conversion_rate -> group_conversion_rate), and also return the metric as group_conversion_rate in the API response.

Custom Property Breakdown and Goal Conversions would still stick with conversion_rate.

[apata]

True! The reason we're somewhere in the middle is because I didn't want to refactor the legacy internal endpoints, CSV exports, and v1 Stats API responses. I expect that they are currently consistent with each other.

What we could do is conditionally remap order_by: [conversion_rate, direction] to order_by: [group_conversion_rate, direction] in the legacy backend. I opted to make the dashboard aware of the difference between the two because I anticipate the dashboard on v2 API to keep this awareness.

[RobertJoonas]

Good point about the consistency between Stats API, CSV export and the dashboard. Makes sense to keep the frontend only aware of conversion_rate, and do the mapping on the backend.