Optimize binlog event deserialization

[shirolimit]

The PR aims to speed up MySQL binary log client by changing how events are deserialized.

Instead of reading data byte-by-byte from ByteArrayInputStream it fully buffers binlog event in memory as RawBinaryLogEvent and then uses BinaryLogEventDataReader for deserialization. The interface of BinaryLogEventDataReader is kept similar to library's custom ByteArrayInputStream to simplify migration.

In my experiments, this improves binlog extraction speed by up to 300% (in case we do nothing with extracted events).
I also tried buffering data in byte[] and wrapping it into ByteArrayInputStream, it was faster than existing approach but still 2 times slower than the proposed one.

The PR also introduces some minor optimizations to row parsing (e.g. datetime) and a bunch of unit tests for existing deserializers.

[shirolimit]

Force-pushed after rebasing on the latest main.

[jmlw]

I don't see any obvious issues; especially since the majority of changes are duplication to utilize a different input object

[DylanFlanders]

Some minor comments but overall it's looking good to me

[DylanFlanders]

I'm having trouble understanding the blockLength in the ByteArrayInputStream version of available(). Do you have some more insight there? It seems in the new data reader version, the buffer is the "block" and we resize the buffer limit in enterBlock. Whereas in the old input stream version, it seems a bit more hacky and has to block off portions of the input stream?

[shirolimit]

In ByteArrayInputStream blockLength was used as a running value, i.e. it contained the number of bytes available for the current block. The stream updated blockLength on every read but it couldn't go below zero unless we skipToTheEndOfTheBlock. In the end, what they tried to achieve is to avoid reading from a block boundary which is needed for parsing some events.

The reader version achieves the same by manipulating ByteBuffer's limit.

[DylanFlanders]

It looks like this covers a number of branches in AbstractRowsEventDataDeserializer#deserializeCell but not all. Are there some column types that are more difficult to add than others? I'd be happy to try to help here so we can cover AbstractRowsEventDataDeserializer changes

[shirolimit]

That's true, we don't cover all possible data types and branches here. I totally agree that ideally we should cover all the branches and methods but I decided not to do that to keep the PR smaller. Also, I didn't set a goal to improve the library's code coverage to 100%, just enough of them to be confident in my changes.

For row deserialization classes most of the changes are just overloads that use the same method names thus I decided to add only a few tests.

1. Would it be better to add more unit tests to cover all cases and branches?
   It definitely would, the library is a crucial part of binlog syncs and we want it to be stable.

2. Is it required to add them to this PR?
   I believe it shouldn't be a stopper considering the changes introduced to the class.

I'd propose to leave it as is for now and create a backlog task to improve library's code coverage.
What do you think?

[DylanFlanders]

Okay that makes sense to me. And thank you for the many tests that were added here!