DBZ-1719 Create an ErrorHandler for Capturing destinations

[KMohnishM]

PR Description

Fixes debezium/dbz#1719
Currently, when change events are captured and sent to destinations, there is no built-in mechanism to capture/handle transient exceptions or apply custom retries. This PR introduces an ErrorHandler interface and a default exponential backoff retry mechanism to capture exceptions and gracefully retry event consumption.

Proposed Changes

1. Configuration SPI (debezium-quarkus-engine-spi):
   • Added configuration options to DebeziumEngineConfiguration.Capturing under default interface methods returning Optional.empty() for backward compatibility:
     • quarkus.debezium.capturing.error-handler (name or class of the custom handler)
     • quarkus.debezium.capturing.error-handling.max-retries
     • quarkus.debezium.capturing.error-handling.initial-delay-ms
     • quarkus.debezium.capturing.error-handling.max-delay-ms
     • quarkus.debezium.capturing.error-handling.delay-multiplier
2. Error Handling Architecture (debezium-quarkus-engine):
   • ErrorHandler Interface: Introduced to wrap change consumers. Provides default no-op methods for both batch-oriented (QuarkusChangeConsumer) and single-record-oriented (SourceRecordEventConsumer) capture interfaces.
   • DefaultRetryErrorHandler: Implements exponential backoff retry loop using the configured delay settings.
3. Integration:
   • Modified DefaultChangeConsumerFactory and SourceRecordEventProducer to resolve the CDI bean / default error handler and wrap the respective change consumers.
   • Injected the error handlers and runtime configuration via GeneralChangeConsumerProducer.
4. Dependency Resolution:
   • Added io.debezium:debezium-config dependency to the engine runtime pom.xml to fix missing class errors (io.debezium.config.Configuration) caused by the split of debezium-common into debezium-util and debezium-config.

Verification & Testing

Added three new test classes verifying all aspects of the error handling and retry mechanism:

1. DefaultRetryErrorHandlerTest: Verifies retry counts, backoff delay increases, recovery, and final exhaustion propagation for both batch and single event interfaces.
2. DefaultChangeConsumerFactoryTest: Verifies that the factory wraps the batch consumer in the resolved error handler.
3. SourceRecordEventProducerTest: Verifies that the producer wraps the single-event consumer in the resolved error handler.

All 32 modules build and pass tests cleanly.

[KMohnishM]

@kmos Could You please review the PR when you get some time , Thanks !

[kmos]

@KMohnishM sorry for the late reply but I wasn't convinced by your last message. My concern related your proposal is that you are exposing to the user the ChangeEvent which is an internal of the embedded engine. We want to expose only the new apis like CapturingEvent. The general idea is ok but the proposed API should use the Quarkus Extensions API

[kmos]

please take a look to: #68 (comment)

[KMohnishM]

Hi @kmos,

Thank you for the feedback!

I have refactored the implementation to use only the Quarkus Extensions API:

1. Removed ChangeEvent and RecordCommitter: Updated the signatures in ErrorHandler to accept CapturingEvents<BatchEvent> (for batches) and CapturingEvent<SourceRecord, SourceRecord> (for single records).
2. Introduced Functional Callbacks: Added two simple functional callback interfaces ErrorHandler.BatchConsumer and ErrorHandler.EventConsumer to allow error handlers to delegate execution cleanly without direct reference to the underlying engine consumers.
3. Updated Tests: Refactored all corresponding tests to reflect the new API signature, and verified that all tests compile and pass successfully.

Please let me know what you think when you have a moment. Thanks!