feat: Restore record store, processors and logs from checkpoints

[chubei]

This is the followup of #1854.

In this PR, in addition to writing checkpoints of the record store, we restore the record store and log from the checkpoints.

We also write checkpoints of processors. Now every processor implements serialize to dump its state to an Object. Upon restart, the ProcessorFactory::build gets an additional parameter checkpoint_data, which is the data that was dumped during one of the serializes. Every processor also restores its state from checkpoint_data.

However, due to the fact that ConnectorSource currently can't start from a checkpoint, the processor restoring functions won't actually run. We'll address the connector restart problem in another PR.

[chubei]

I pushed another commit with a bug fix but Github has trouble verifying it. main...chubei:dozer:feat/checkpoint_restore

[Jesse-Bakker]

Cursor seems like a re-implementation of the Buf trait from bytes. We might just want to use bytes. It is already in our dependency tree anyway.

Furthermore, I think a lot of the serialize implementations should probably be impl Serialize instead. Object can implement Write, so we can just bincode::serialize_into into it.

[chubei]

Buf looks like overkill? I just want one consume method and it's not even in Buf because it can be composed of multiple chunks.

I'm not using serde because the serialization of ProcessorRecord needs access to an extra parameter ProcessorRecrodStore. Again not expert on serde so don't know how to represent that.
I'm using serde and bincode (see serialize_bincode) whenever possible.

[Jesse-Bakker]

Buf looks like overkill? I just want one consume method and it's not even in Buf because it can be composed of multiple chunks.

I meant that it also implements most of the deserialize_<type> functions, like Buf::get_u64, and it can also supply a Read, so serde can deserialize from it. It does panic if there are not enough bytes in the buffer, however, so that probably makes it unsuitable for us.

[Jesse-Bakker]

Generally looks very good. I think putting effort in using serde better is not a good use of our time right now, and the current implementation looks correct and performant.