feat(gateways): Kafka Gateway add DescribeGroups and ListGroups Keys - #4401

Which issue does this PR address?

Closes #3548
Relates #3560

Rationale

kafka-consumer-groups.sh and other admin clients learn classic group membership by sending DescribeGroups and ListGroups. This gateway already coordinates those groups in memory for join, heartbeat, sync, and leave, and nothing on the wire would report that state, so those tools could not inspect a group on this coordinator.

What changed?

DescribeGroups versions 0-6 and ListGroups versions 0-5 now read that same in-memory coordinator. A live group is PreparingRebalance, CompletingRebalance, or Stable. A named group that is not in the map is Dead. Version 6 also returns GROUP_ID_NOT_FOUND (69) and Group {id} not found.. Older describe versions return Dead with error 0, because a v6 client treats error 0 as a group that exists.

Each member includes its id, its instance id, the subscription metadata of the selected protocol, and its assignment bytes. client_id and client_host stay empty, because the coordinator does not retain the request header's client id or the connection's peer address. include_authorized_operations stays at the omitted sentinel. There is no group ACL bitfield. ListGroups sets group_type to classic. From v4 a state filter, and from v5 a type filter, keep a group only when the filter is empty or one entry matches, case-insensitively after trim. A filter value this coordinator does not use matches nothing, and the response error stays 0.

ListGroups does not expire sessions. Expiry runs on a request that names a group, and a list names none, so listing must not open rebalances as a side effect of reading. DescribeGroups ticks each named group once, after the requested ids are deduped, so a repeated id is one group and one tick. The describe frame is priced from lengths already stored, before any member snapshot is copied. If that body would exceed max_frame_size, the connection closes. An oversized ListGroups body closes the same way. The list is priced before it is encoded, because the request shape guard never sees the groups that will be written back.

Join rejects a protocol_type, a client-supplied member_id, or a group_instance_id longer than i16::MAX. DescribeGroups v0-v4 and ListGroups v0-v2 encode those fields as legacy strings, and a longer value cannot be written back. When the member id is generated, the instance id is the prefix and 37 bytes are reserved for -{uuid}, so the id itself still fits that cap. A failed DescribeGroups decode closes the connection: the response has no top-level error field, and an empty group list would look like success. A failed ListGroups decode returns INVALID_REQUEST (42). Groups stay in process memory only. A restart drops membership. Committed offsets stay in Iggy.

Local Execution

• Passed:
• cargo fmt -p iggy-gateway-kafka (exit 0);
• cargo test -p iggy-gateway-kafka --lib group:: (79 passed);
• cargo test -p iggy-gateway-kafka --test consumer_group_tests (44 passed);
• cargo clippy -p iggy-gateway-kafka --all-targets -- -D warnings

AI Usage

If AI tools were used, please answer:

1. Which tools? Claude
2. Scope of usage? Implementation
3. How did you verify the generated code works correctly?Manual walkthrough, testing
4. Can you explain every line of the code if asked? Yes