[CT-3484] Support coarser granularity for cumulative metrics

[QMalcolm]

Housekeeping

• I am a maintainer of dbt-core

Short description

Unlike other metrics types, we require the user to give us additional information about how they want to aggregate a cumulative metric to a different grain to avoid incorrect results. For example, if we naively aggregate a daily cumulative metric to week, we would perform a sum of cumulative values for that week which would yield incorrect results. Thus we want to allow the user to specify the min or max of a window, and we return the value of the cumulative metric at that point in time. For example, if you request a cumulative metric by month and specify the window_choice as min, we return the cumulative value at the beginning of the month.

To better ensure cumulative metrics are being aggregated properly we need to expand the Metric definition. Specifically a window_choice attribute should be added to the type_params of Metric

metrics:
  - name: my_cumulative_metric
    type: cumulative
    type_params:
      measure: revenue
      window_choice: min # New optional. Defaults to min. Options: min, max

Acceptance criteria

People can specify a window_choice attribute on Metric type params

Impact to Other Teams

• Semantic Layer - The semantic layer can't begin using this until we support it
• Cloud artifacts - This change will change the v12 manifest that goes out with 1.8

Will backports be required?

Not sure if required, but the SL team would prefer a backport to 1.7

Context

This issue should not be considered ready to work on until the work is done in dbt-semantic-interfaces, because the schema we need to implement isn't finalized until that point. Currently there does exist an issue for this work in dbt-semantic-interfaces.

[Jstein77]

Closing this since it's not needed anymore. We added the period_agg field in this PR which accomplishes the same thing.

[FishtownBuildBot]

Opened a new issue in dbt-labs/docs.getdbt.com: dbt-labs/docs.getdbt.com#6175