Fix(clickhouse): support non-datetime time column partitioning

[treysp]

The Clickhouse adapter automatically partitions incremental by time models if the time column is not included in any partitioning expression.

Clickhouse strongly recommends against fine-grained/small partitions. Therefore, the automatic partitioning "floors" the time column to weekly granularity with the toMonday() function.

toMonday() only accepts date/datetime input types, so we currently error if the time column is string type.

This PR allows non-date/datetime time columns by:

• If time column type known and date/datetime, pass column directly
• If time column type known and NOT date/datetime, cast time column to DateTime64 before passing to toMonday() then cast output back to original time column type
• If time column type not known, cast time column to DateTime64 before passing to toMonday()

Implementation note

This PR moves the partitioned_by property from the ModelMeta to _Model class so it can access the _Model column_to_types property.

[georgesittas]

Nice, thanks for addressing comments 👍

[swt30]

Hey @treysp what version of Clickhouse are you using? I am experimenting with sqlmesh + clickhouse and finding that this causes an error because DateTime64('UTC') needs scale as the first parameter, at least in the latest Clickhouse. I'm new to Clickhouse so perhaps I'm missing something here?

Adding a scale of 6 here and just below fixes the problem. But the choice of 6 feels a bit arbitrary. What if the column were a nanosecond-precision string-formatted timestamp?

[treysp]

Thanks for reporting - that looks like a bug.

Precision is essentially arbitrary, so my inclination would be to go for nanosecond to prevent truncation. Do you see any issues with that? Pandas handles nanosecond timestamps, so conversion to Python should be ok.

[treysp]

Addressing this in #3582