changefeedccl: support the various timestamp column types in Avro changefeeds

[rolandcrosby]

We need to support the various timestamp column types (specifically, the ledger workload depends on timestamptz, but we should figure out mappings for all of the SQL timestamp types we support). This likely needs additional research about common conventions used in the Avro/Confluent/Kafka ecosystem, since AFAIK Avro doesn't have a native/straightforward timestamp representation.

[rolandcrosby]

Here's what BottledWater, a (now-unmaintained) Postgres-to-Kafka connector, does.

And here's the Debezium Postgres-to-Avro type mapping.

I'm starting to think ISO 8601-formatted timestamp strings might be the rational thing to do here, since they natively let you specify time zone offsets and various levels of precision, but am open to persuasion in any direction.

[rolandcrosby]

@danhhz I see we now support TIMESTAMP (with and without time zone, since internally "with time zone" is converted to and stored as UTC) in Avro. Both of these are output as an Avro long with a logicalType of timestamp-micros. We do not yet support TIME or DATE in Avro. I think it makes sense to represent those types the same way (i.e. as a count of microseconds, just with no day-fraction part for DATE and only a day-fraction part for TIME), since that more or less matches what we do elsewhere in SQL. Do you have any objections to that proposed encoding?

Also, can we use the same encoding for INTERVAL? Our docs say that "intervals are stored internally as months, days, and nanoseconds", so I suspect the same encoding should work, but wanted to check if there are any gotchas you're aware of.