chore: refresh automatic content (#1090)

Author: mensfeld

Changelog/Rdkafka.md

@@ -4,6 +4,7 @@
 # Rdkafka Changelog
 
 ## 0.29.1 (Unreleased)
+- [Enhancement] Add `Admin#list_consumer_groups`, wrapping librdkafka's `ListConsumerGroups` admin API. It returns a cluster-wide listing of consumer groups (each with its `group_id`, `is_simple_consumer_group` flag, and state) in a single request that librdkafka fans out to every broker, plus any per-broker errors, without a manual per-broker fan-out.
 - [Enhancement] Name the failing partition and topic in the `RdkafkaError` raised for per-partition `list_offsets` errors (previously a bare error code), preserving the per-partition context the pre-batching `Consumer#lag` watermark errors carried.
 - [Enhancement] Add `Consumer#list_offsets`, mirroring `Admin#list_offsets`, so batched offset queries (one `ListOffsets` request carrying all requested partitions, fanned out to the partition leaders by librdkafka) can be issued on an existing consumer handle without opening a dedicated admin connection, and rebuild `Consumer#lag` on top of it: lag is now computed from a single batched end-offsets query instead of one blocking `query_watermark_offsets` broker roundtrip per partition. To receive the results, consumer clients now register the librdkafka background event callback, so librdkafka spawns its internally-managed background thread for consumers as well. `Consumer#lag` keeps its exact pre-batching semantics: it forwards the consumer's configured `isolation.level` to the batched query (librdkafka resolves the per-partition watermark query with that level, so end offsets stay LSO-based for the default `read_committed`), surfaces a timeout of the batched query as an `RdkafkaError` (`timed_out`), and now also raises `ClosedConsumerError` when called on a closed consumer.
 - [Fix] Make `NativeKafka#close` fork-aware so a forked child no longer segfaults on exit. librdkafka is not fork-safe: `fork` copies only the calling thread, so the background/broker threads backing a handle do not exist in the child. When the child exited, Ruby ran the GC finalizers of every inherited client, each calling `rd_kafka_destroy` on a handle whose threads were gone - dereferencing defunct thread state and crashing (SIGSEGV), and risking a deadlock on a mutex inherited in a locked state. Handles now record their creator pid and report as closed in any other process, so every `#close` path (including exit-time finalizers) skips the native teardown for inherited handles and leaves it to the process that owns the threads.