Use `MetricTimeDefaultGranularityPattern` to resolve `metric_time` granularity

[courtneyholcomb]

Resolve metric time using new spec pattern in group by and filter nodes. This is a change from defaulting to the minimum time granularity for metric_time. Now we will use the max default granularity for the requested metrics.

Note the snapshot updates. These reflect another behavior change in which we don't error if metric_time is queried for metrics with two different default granularities. Instead, we choose the larger of the two, which is guaranteed to work for both metrics.

[courtneyholcomb]

Changes look good, but I am wondering about the behavior change for how the default now allows for what was previously an error condition. From what I remember, we wanted to error out to make it easier to see from the configs what the granularity for a time dimension was. Has that thought changed from the product side?

@plypaul this is my understanding of the behavior change (mentioned in the PR description!). This scenario occurs if you query multiple metrics or a derived metric with different agg_time_dimensions. That means there are multiple default granularities for those metrics/input metrics.

• Previously, we would error out in this scenario and force the user to specify a grain.
• Now, we don't error. Instead we choose the larger of the default granularities, since that is guaranteed to be supported by all of the metrics. (Previously that might not have been true since cumulative metrics had granularity restrictions, but they don't anymore.) This behavior change was agreed upon by product.