Add & validate cumulative type params & period agg

[courtneyholcomb]

Resolves #289
Completes SL-2363
Completes SL-2364

Description

Move cumulative metric type params to a nested key within type_params called cumulative_type_params.
Add new period_agg field with options FIRST, LAST, and AVERAGE. (Note we chose FIRST and LAST because that language aligns with the window function syntax we'll use for those - FIRST_VALUE and LAST_VALUE.) This will be used when aggregating cumulative metrics to non-default time granularities.

Checklist

• I have read the contributing guide and understand what's expected of me
• I have signed the CLA
• This PR includes tests, or tests are not required/relevant for this PR
• I have run changie new to create a changelog entry

[linear]

SL-2363 DSI: Add config option `period_agg` / `grain_agg`

SL-2364 Add `cumulative_type_params` to YAML spec

[QMalcolm]

This is great! However, I'm trying to think through both the system as a whole (core, DSI, MetricFlow), DSI by itself, the deprecation/migration path in both of those, and the end user experience. Taking that all into account, I think we should make some changes

1. MetricFlow should only have to pull from one place
   a. Ideally it should be able to pull directly from metric.type_params.cumulative_type_params.<field> and not think about metric_type_params.<deprecated_field>
   b. DSI can ensure this by either
   1. Including a new transformation (I believe MetricFlow still runs transformations) which sets the new paths if they aren't already set when the deprecated paths are.
   2. providing a metric level accessor which does the munging
      • this is problematic in that it creates more "future" work in that we'll want to deprecate the accessor at some point and end up migrating MetricFlow not once but twice.
   3. at post instantition of a metric, populating the cumulative_type_params from the old deprecated fields (only for cumulative_type_param fields which are None)
2. dbt-core should always populate the cumulative_type_param fields if they are available
   a. if the user specifies them directly, perfect
   b. if the user specifies them via the deprecated fields, but not directly, then we use the deprecated fields

Points (1.b) and (2) mean that our desired state for the time being is that there is duplication. Thus both being defined shouldn't be an error, it should be expected. What should be an error is if they are different.

Additionally, people who use dbt-core have the ability to silence warnings. Which might happen for these warnings as they will likely be noisy. It is basically guaranteed to happen for anybody who currently has a cumulative metric defined. Unfortunately silencing happens via log event type and all DSI validation logs get logged out via the same event type. That means silencing this DSI validation issue will silence all DSI validation issues (not great). This isn't something we should fix in this PR, but it's probably worth SL and Core working together on how to make this better.

[QMalcolm]

We actually want them to be duplicated I think. In which case we should change this error to be if the fields are different.

[courtneyholcomb]

@QMalcolm thank you for the thorough feedback! Just added a couple commits to add the transformation and update the validation if you want to take another look.

[QMalcolm]

Thank you for working through the change requests ❤️ This looks great!

Also, thank you for being smarter than me. In my change requests, I said that we should error if the deprecated path values and the new path values differed. The edge case in what I said is that it should be allowable for either to be None. How you set up the validation rule handles that 🚀

[courtneyholcomb]

Note: We have a release for 0.6.0 coming soon. This should not merge until after that release - otherwise users will get validation warnings for cumulative_type_params before those fields are actually supported in MF.