Add CLI support for time_frame arrays in metrics

What does this MR do and why?

Related to #478008 (closed)

After !167201 (merged) has been deployed & tested on production, we now know that metrics with time_frame array are working.

Now, we add official support for them, by making the CLI use them as the default & adding them to our documentation.

This also updates all of the tests that were previously creating a separate metric definition for each time_frame.

References

Please include cross links to any resources that are relevant to this MR This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

To test this, run the internal events CLI:

ruby scripts/internal_events/cli.rb

And try to create new metric definition with time_frame array. Then, verify that the new metrics are working, using the Manual testing in GDK commands listed by the CLI when using the view usage command of the CLI.

doc/development/internal_analytics/metrics/metrics_dictionary.md

@@ -7,7 +7,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
 # Metrics Dictionary Guide
 
 [Service Ping](../service_ping/index.md) metrics are defined in individual YAML files definitions from which the
-[Metrics Dictionary](https://metrics.gitlab.com/) is built. Currently, the metrics dictionary is built automatically once a day. When a change to a metric is made in a YAML file, you can see the change in the dictionary within 24 hours.
+[Metrics Dictionary](https://metrics.gitlab.com/) is built. Currently, the metrics dictionary is built automatically once an hour. When a change to a metric is made in a YAML file, you can see the change in the dictionary within 1 hour.
 This guide describes the dictionary and how it's implemented.
 
 ## Metrics Definition and validation
@@ -29,7 +29,7 @@ All metrics are stored in YAML files:
 WARNING:
 Only metrics with a metric definition YAML and whose status is not `removed` are added to the Service Ping JSON payload.
 
-Each metric is defined in a separate YAML file consisting of a number of fields:
+Each metric is defined in a YAML file consisting of a number of fields:
 
 | Field                        | Required | Additional information |
 |------------------------------|----------|------------------------|
@@ -38,7 +38,7 @@ Each metric is defined in a separate YAML file consisting of a number of fields:
 | `product_group`              | yes      | The [group](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) that owns the metric. |
 | `value_type`                 | yes      | `string`; one of [`string`, `number`, `boolean`, `object`](https://json-schema.org/understanding-json-schema/reference/type). |
 | `status`                     | yes      | `string`; [status](#metric-statuses) of the metric, may be set to `active`, `removed`, `broken`. |
-| `time_frame`                 | yes      | `string`; may be set to a value like `7d`, `28d`, `all`, `none`. |
+| `time_frame`                 | yes      | `string` or `array`; may be set to `7d`, `28d`, `all`, `none` or an array including any of these values except for `none`. |
 | `data_source`                | yes      | `string`; may be set to a value like `database`, `redis`, `redis_hll`, `prometheus`, `system`, `license`, `internal_events`. |
 | `data_category`              | yes      | `string`; [categories](#data-category) of the metric, may be set to `operational`, `optional`, `subscription`, `standard`. The default value is `optional`. |
 | `instrumentation_class`      | no       | `string`; used for metrics with `data_source` other than `internal_events`. See [the class that implements the metric](metrics_instrumentation.md). |
@@ -59,12 +59,15 @@ The `key_path` of the metric is the location in the JSON Service Ping payload.
 
 The `key_path` could be composed from multiple parts separated by `.` and it must be unique.
 
-We recommend to add the metric in one of the top-level keys:
+If a metric definition has an array `time_frame`, the `key_path` defined in the YAML file will have a suffix automatically added for each of the included time frames:
 
-- `settings`: for settings related metrics.
-- `counts_weekly`: for counters that have data for the most recent 7 days.
-- `counts_monthly`: for counters that have data for the most recent 28 days.
-- `counts`: for counters that have data for all time.
+| time_frame | `key_path` suffix|
+|------------|------------------|
+| `all`      | no suffix |
+| `7d`       | `_weekly` |
+| `28d`      | `_monthly` |
+
+The `key_path`s shown in the [Metrics Dictionary](https://metrics.gitlab.com/) include those suffixes.
 
 ### Metric statuses
 
@@ -88,7 +91,7 @@ Metric definitions can have one of the following values for `value_type`:
 
 ### Metric `time_frame`
 
-A metric's time frame is calculated based on the `time_frame` field and the `data_source` of the metric.
+A metric's time frame is calculated based on the `time_frame` field and the `data_source` of the metric. When `time_frame` is an array, the metric's values are calculated for each of the included time frames.
 
 | data_source            | time_frame | Description                                     |
 |------------------------|------------|-------------------------------------------------|