Fix resuming binlog streaming #156

[kolbitsch-lastline]

A mysql replication event for changing data is always started by
sending a TableMapEvent (describing the table to be changed),
followed by one or more RowsEvent (containing the data to be
changed). If multiple consecutive RowsEvent events are sent for the
same table, the TableMapEvent is typically skipped (after sending it
once), meaning that resuming from such a binlog is not possible.

Resuming at a binlog position between the TableMapEvent and a
RowsEvent is not possible, as the binlog streamer would miss the
table definition for following DML statements.

This commit tracks the position of the most recently processed
TableMapEvent and uses this for resuming (skipping any actual events
between the last write and resume position that were already
processed).

[fjordan]

👋 Apologies for the delay in reviews here.

Thank you for your contribution - this does indeed solve the problem you're describing.

After running into this problem while doing some binlog streaming against the target for a separate and new feature we're looking to soon add, I took a slightly different approach that led to the same basic resolution, but with fewer changes (primarily by moving the last resumable position to the DMLEvent instead of creating a new BinlogEvent struct). You can see thee proposed alternative here: #168

I also borrowed your test and slightly modified the assertions a bit, but I wanted to make sure you knew I was intentionally reusing your work 🙏 😄

[kolbitsch-lastline]

glad to hear it was useful and thanks for the pointer