updated go-mysql library

[shlomi-noach]

Periodic update of the go-mysql library. Among other things, tackling #496

[shlomi-noach]

This one is failing local tests in the meantime.

[shlomi-noach]

There's an inconsistency of timzone handling between time2 and datetime2, and gh-ost is unable to treat the two in the same way. For now, I'm not updating the go-mysql library.

[druud62]

In MySQL, the timestamp-type is physically stored as a UNIX-epoch-based numeric value,
but the datetime-type is much like a string. (And there is still no datetimezone-type.)

So datetime-values should always be copied as-is, as they have no inherent timezone.

This of course makes alters that switch between these types problematic,
for example because a datetime-value can be non-existent in the current timezone.
https://bugs.mysql.com/bug.php?id=85641
And much more so if not all involved database servers run with the same timezone config.

With timestamp-values, one should simply always copy the raw UNIX-epoch-based numerical value, but there is no good functionality for that on the SQL-level.

[shlomi-noach]

In MySQL, the timestamp-type is physically stored as a UNIX-epoch-based numeric value,
but the datetime-type is much like a string. (And there is still no datetimezone-type.)

So datetime-values should always be copied as-is, as they have no inherent timezone.

I am indeed very much aware of both. Interestingly, B.com delivered the first non trivial TZ use case where the two did not agree with each other.

Also of interest is that binary logs always store timestamps as UTC, so they convert them, while datetimes are of course never converted.
This is also much about the library I use to read events from the binary logs.

[shlomi-noach]

go-mysql has been updated in #684. This PR is redundant.