Evaluate transaction handling / clickhouse-sink-connector

[bmtcril]

We should evaluate whether https://github.com/Altinity/clickhouse-sink-connector is a good replacement for our MySQL based sinks. It may be a more robust solution and get around a number of issues with the current sinks & Celery saturation / transaction handling.

If it seems like it won't be a good choice for us, we should at least convert the remaining MySQL sinks to use the on_commit handler so that we can work around issues related to rollbacks, trying to read uncommitted data, etc. See this #108 for more information.

[bmtcril]

I've dug into this and attempted to add the service to tutor-contrib-aspects. Here are the findings:

• There are two versions of the connector, one that uses Kafka as a pipeline for Debezium and a "lightweight" version that uses Debezium embedded. Since we don't currently require the event bus and may never require a Kafka based bus I focused on the lightweight version.
• Anything involving MySQL binlogs is always going to be difficult and complicated. There are a ton of settings for even the lightweight version, which we can make educated guesses at for defaults but we'd need to make sure appropriate patches are available to override basically anything for more complicated MySQL deployments.
• The version of Debezium it's using doesn't support MySQL 8.4+. I've opened an issue for it here: MySQL 8.4 support Altinity/clickhouse-sink-connector#994 and when that clears we can reevaluate it.
• I don't believe at the current time we can use Debezium embedded by itself, we would have to basically reinvent the Altinity wrapper.
• There are a number of scary looking issues on their board, which I would expect in anything working in this space due to the complexities involved. I'm hoping a few of them will clear up by the time we test again with 8.4 support.
• We currently do some normalization of data as part of the event sink, and would need to find a way to emulate that or wrap the ingested tables as part of this work, I don't think either solution is much of a problem except in cases where we're using the dump timestamp to get latest rows.