Consolidate query interface params

[DevonFulcher]

Resolves SLA-218 (internal to dbt Labs)

Description

This PR makes the Dimension, TimeDimension, and Entity objects that are passed into the where filter Jinja template implement protocols. These protocols allow for different implementations of these objects depending on the context (group_by, where, order_by parameters) while also constraining these implementations to all have the same method signatures. This will create consistency across these contexts.

The Dimension protocol is also implemented for parameters in certain methods (i.e. GroupByOrderByDimension). This will allow for more complex Dimension objects in the future that aren't feasible to serialize into a string, such as Dimension('demographic').grain('month').alias('monthly_demographics'). These parameters are added as optional parameters to these methods, so everything should be backward compatible.

I added some unit tests. This change is mostly refactoring existing behavior to implement protocols and adding additional optional parameters. These optional parameters just transform into the existing parameters. So, I relied on the existing tests to ensure no breaking behavior.

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[WilliamDee]

There's this whole thing about inheriting the Protocol classes in the implementation class that we had, don't really remember what we landed at there, but @tlento or @plypaul would know. In DSI, Paul made the ProtocolHint class for this, not sure if we would want to use that here too.

[DevonFulcher]

Added ProtocolHint to the implementations.

[tlento]

Checkpoint review, I'm not quite done.

I'm not sold on the factory class pattern but I have nothing better to offer that will work with jinja, so this is probably one of those cases where it's better for us to proceed with minor readability updates and revisit if we need to.

[DevonFulcher]

I'm not sold on the factory class pattern

That pattern isn't strictly necessary. It helps to ensure that all of the constructors in Jinja have the same interfaces. I think it is worth the added indirection for greater consistency, but I can remove it if you prefer.

[tlento]

Per our discussion, we are going to do the following here:

1. Clean up the protocols a bit in some way in order to ensure there are property accessors for MetricFlow to use for building specs and so forth behind the API, and property configuration methods for the callers to implement so users can configure things on the client side
2. Leave anything other than minor cleanup for follow-up PRs
3. Figure out if we want to move to something like group_by: Optional[Sequence[Union[str, NonAggregateParameter]]] and, if so, have a separate PR where we get that all working nicely

I'm requesting changes just so I can get an alert when this is ready - please request review from me when you update. GitHub makes you do this manually, which always annoys me, but I haven't found a better mechanism.

[DevonFulcher]

I changed the factories to return individualized protocols instead of all sharing the QueryParameter protocol. While the parameters are similar in some respects (they all might have an alias), they can also be different (only Dimension has grain). I wanted these protocols to be separate so they could evolve independently. This can be changed later.

Instead, I use QueryParameter as the read-only protocol for MF to get grain and name for an object. Since, both QueryParameter and QueryInterfaceDimension have a grain property, they can't be implemented by the same class. This is somewhat limiting, but I found it an okay tradeoff to have a more Pythonic interface instead of QueryParameter having a get_grain property or something similar.

[tlento]

Looking much better, thank you!

I'm mildly concerned about the layers of indirection being confusing to readers of the future, particularly if they read by module instead of in coordination as these changes appear in this PR.

For now I think this is best addressed via documentation, and I've left a couple of minor pointers inline.

Unless you feel like you want another review pass you may update and merge at your convenience! This might merit a squash and merge operation, or at least a rebase -i and force push to clean up the history in this branch. It's a little gnarly commit-wise.

Thanks!