fix: client reconnect: messages held before the current buffer aren't replayed

[Naros]

Problem

When a client reconnects and sends CONTINUE with a position earlier than the last message it received, any unconfirmed messages sitting in buffers older than the one the writer currently occupies are never re-sent. The client is only given messages that follow the requested position, so those messages are silently skipped with no errors or warnings. For a consumer that resumes from its last committed position rather than its last received position, this results in data loss on restart.

Cause

WriterStream::processContinue calls resetMessageQueue() to rewind the stream. That rewind used the head of whichever buffer the writer happened to be in:

oldSize = builderQueue->start;

builderQueue points at the writer's current position, not at the oldest data still retained. Every buffer before it is still held; buffers are only released once the client confirms them, but the read restarts past them, so their contents are never walked again.

A second related defect is that confirmMessage sets OUTPUT_BUFFER::CONFIRMED on a message, and the main loop pops confirmed messages off the queue head. A message walked over a second time during a replay still carries CONFIRMED from the earlier pass, so it is discarded before the reconnecting client has acknowledged it.

Proposed solution

Rewind to the oldest buffer still held.

builderQueue = builder->firstBuilderQueue;
oldSize = builderQueue->start;
if (unlikely(oldSize == Builder::BUFFER_START_UNDEFINED))
    oldSize = 0;

A buffer that has not yet had a message end in it has no message boundary to replay from, so the read resumes at its head. BUFFER_START_UNDEFINED moves from protected to public so that the writer can test for it.

This is seen as safe because a buffer is only released once it's confirmed, so firstBuilderQueue is the earliest position any client can legitimately ask to continue from. Metadata::isNewData() then filters forward to the requested c_scn / c_idx so the extra messages walked are discarded rather than resent; the change therefore only costs a longer walk, never duplicates.

For Debezium, it would be useful if this could be backported to 1.9 and earlier, based on supported versions. This is because Debezium isn't currently compatible with 2.0, which has changed how some parts of the data work.