Add parallel incremental snapshot for relational connectors

[MrIvv]

Feature Request

Description

Add support for parallel incremental snapshots, with table-level workers running concurrent chunk reads inside a single DBLog watermark window.

Motivation

The current incremental snapshot implementation has two scaling limitations:

1. Single-threaded: Tables are processed one at a time, leaving CPU and I/O bandwidth underutilized on multi-core hosts.
2. Idle workers in batch-and-wait scheduling: When tables within a parallel batch have different sizes, faster workers sit idle until the slowest table completes before the next batch can start.

Proposed Changes

1. Parallel snapshot infrastructure: ParallelIncrementalSnapshotCoordinator (per-table window buffers + JDBC connection pool + worker activation policy), TableSnapshotContext, TableSnapshotWorker. The per-round worker pool lives in AbstractIncrementalSnapshotChangeEventSource using a fixed-size ExecutorService + CompletionService, scoped to the round and shut down at its end.
2. Work-queue scheduler: Replaces batch-and-wait with a shared ConcurrentLinkedQueue — workers pick the next table immediately upon completing the current one, eliminating cross-table idle time. JDBC connections are held by the worker across all its tables.
3. Retry policy with exponential backoff: New RetryExecutor in debezium-util. Generic over Callable/Runnable, accepts any retryable predicate, exponential backoff with jitter, configurable cap. Used by the parallel chunk round to recover from transient JDBC failures (lock timeout, deadlock victim, broken connection in the pool) without aborting the snapshot.
4. PostgreSQL read-only support: Parallel-safe JDBC connections via createSnapshotConnection() override in PostgresReadOnlyIncrementalSnapshotChangeEventSource.

Backward Compatibility

• Default snapshot.max.threads=1 preserves original single-threaded behavior
• createSnapshotConnection() throws UnsupportedOperationException by default (graceful degradation for connectors that don't yet support parallel snapshots)
• Notification format unchanged (same aggregateType="Incremental Snapshot" and per-type schema)
• No breaking API changes

[MrIvv]

Update: Work-Queue Pattern Added

Added a work-queue pattern to processTablesInParallel() that eliminates worker idle time when tables have different sizes.

Problem

The previous implementation split tables into fixed sub-batches and called awaitCompletion() per sub-batch. When tables within a batch had different sizes, faster workers sat idle until the slowest table finished:

Worker-1: |====== A ======|---- idle ----|====== C ======|
Worker-2: |========== B ==========|      |========== D ==========|
                                  ^
                           awaitCompletion()

In production, this caused 10-18 minutes of idle per worker per batch with unbalanced table sizes.

Solution

All tables go into a shared ConcurrentLinkedQueue. Each worker picks the next table immediately upon completing its current one:

Worker-1: |====== A ======|==== C ====|
Worker-2: |========== B ==========|== D ==|
                          ^
                    worker-1 picks C immediately

Key improvements:

• Zero idle time between tables
• JDBC connection reuse — each worker holds one connection for all its tables (vs acquire/release per table)
• Single awaitCompletion() at the end instead of per sub-batch
• Thread-safe via ConcurrentLinkedQueue.poll()

Production Results

• 100+ tables processed with 2 workers
• Workers consistently pick next table immediately from queue (verified in logs)
• Zero idle time observed
• No additional memory overhead (just a ConcurrentLinkedQueue + AtomicInteger counters)

PR: debezium/debezium#7362