feat: OpenLineage integration and Quarkus management interface

[MrIvv]

Summary

Two independent features bundled in a single PR (each in a dedicated commit) for the iceberg sink:

1. OpenLineage output dataset emission — emit DatasetMetadata after each successful Iceberg commit, using the standard DebeziumOpenLineageEmitter API
2. Quarkus management interface — enable a separate HTTP server on port 9000 for health/ready/live endpoints, isolated from the main event loop

OpenLineage integration

In IcebergTableOperator.addToTablePerSchema(), after a successful commit, emit dataset metadata (table name, schema fields, OUTPUT/DATABASE) using DebeziumOpenLineageEmitter.emit(). Falls back to NoOpLineageEmitter when OpenLineage runtime is not configured, so downstream users without OpenLineage continue to work unchanged.

Files:

• pom.xml — add debezium-openlineage-api dependency
• IcebergTableOperator.java — add emitOpenLineageEvent() after commit

Quarkus management interface

Add application.properties with quarkus.management.enabled=true as a build-time property. This enables a separate HTTP server on port 9000 for health/ready/live endpoints, using its own thread pool independent from the main Vert.x event loop.

Why this matters in production: without this, health probes share the same event loop that gets blocked for 10-20+ seconds during Iceberg commits and GCS uploads, causing K8s liveness probes to fail and the pod to restart mid-commit.

Files:

• application.properties — quarkus.management.enabled=true

Backward compatibility

• OpenLineage emission is non-blocking: any failure is caught and logged at DEBUG. No regression for users without OpenLineage configured.
• The management interface is opt-in via the build-time property. Endpoints on port 9000 don't conflict with the existing port 8080 (where the application binds by default).
• No API or configuration changes for existing consumers.

[ismailsimsek]

could we add this setting to user properties instead? or define in the Config class with defaults set to True and 9000. this is not flexible way to do add them.

[MrIvv]

Hi @ismailsimsek, switched the two quarkus.management.* properties to placeholder syntax with sensible defaults:

quarkus.management.enabled=${iceberg.management.enabled:true}
quarkus.management.port=${iceberg.management.port:9000}

Defaults stay true / 9000 so the dist build keeps the K8s-friendly behaviour it has today, but a consumer who rebuilds debezium-server-iceberg with -Diceberg.management.enabled=false (or sets the property in their own application.properties before mvn package) overrides them.

Note that quarkus.management.enabled is a Quarkus build-time fixed property, so users who consume the pre-built dist zip cannot disable it at runtime via env var or properties — they have to rebuild the debezium-server-iceberg sources with the override property to get a different value baked in. Per-build override is the most flexibility we can give without converting the sink into a Quarkus extension.