[ISSUE #10114] Support deleting consumer offset by group and topic

[btlqql]

Problem

A consumer group can accidentally consume a topic, but the current administration API only removes all offsets with the subscription group. Operators cannot clean up one group-topic relationship without affecting the group's progress on unrelated topics.

Closes #10114.

Root cause

Consumer offsets are keyed by topic and group internally, but the broker protocol and mqadmin surface expose only group-wide removal. The precise storage operation was not wired through the broker, client, admin API, and CLI layers.

Changes

• add a dedicated request code and ACL-aware request header for deleting one group-topic offset
• remove the exact key from normal, server-side reset, and pull offset tables, while using the existing persistent offset deletion path
• add broker-side blank resource validation and an idempotent success response
• expose the operation through MQClientAPIImpl, MQAdminExt, and DefaultMQAdminExt
• add the mqadmin deleteConsumerOffset command with required group/topic arguments and a mutually exclusive broker-or-cluster target
• handle a null broker response explicitly instead of relying on Java assertions
• cover exact-key isolation, broker validation/delegation, client success/failure/null responses, CLI parsing, and broker/cluster execution

Impact

This adds an opt-in administration operation and does not change normal offset commits. It deletes only the selected topic@group offset and leaves the consumer group's offsets for other topics intact. Running consumers can commit the offset again, so operators should stop the affected consumer before cleanup when persistent removal is required.

Validation

• mvn -pl broker,client,tools -am -DskipTests -Dspotbugs.skip=true compile
• mvn -pl broker,client,tools -am -DskipTests -Dspotbugs.skip=true test-compile
• ConsumerOffsetManagerTest#removeOffsetByGroupAndTopicTest
• AdminBrokerProcessorTest#testDeleteConsumerOffset and #testDeleteConsumerOffsetRejectsBlankResource
• MQClientAPIImplTest#testDeleteConsumerOffset, #testDeleteConsumerOffsetFail, and #testDeleteConsumerOffsetNullResponse
• DeleteConsumerOffsetCommandTest (8 tests, including direct broker and cluster execution)
• git diff --check

Prior work

#10115 previously explored the same issue but was closed without merge. This PR reimplements the feature on current develop and adds explicit target validation, null-response handling, isolation checks, and broker/cluster command coverage.

[RockteMQ-AI]

Review by github-manager-bot

Summary

This PR adds a new admin API (DELETE_CONSUMER_OFFSET, request code 380) to delete consumer offsets for a specific group+topic combination. The implementation spans broker, client, remoting, and tools modules with comprehensive test coverage.

Findings

• [Info] ConsumerOffsetManager.removeOffset(String group, String topic) — The log message says "clean group and topic offset" while the method name and API are "delete". Consider aligning the terminology for consistency with the existing removeOffset(String group) method which also uses "clean" in its log. This is a minor style point.

• [Info] AdminBrokerProcessor.deleteConsumerOffset() — The null check on offsetManager (line ~1418) returns a response, but the subsequent removeConsumerOffset(topicAtGroup) call on line ~1424 is only executed when offsetManager != null. The logic is correct but could be clearer with an early return pattern or a comment explaining the two-phase cleanup (offset table removal + consumer offset file cleanup).

• [Info] RequestCode.DELETE_CONSUMER_OFFSET = 380 — Fits cleanly in the gap between 370 (RECALL_MESSAGE) and 400 (QUERY_ASSIGNMENT). No conflict.

Positive Notes

• Well-structured implementation following existing patterns (mirrors DELETE_SUBSCRIPTIONGROUP flow)
• Good test coverage across unit tests, processor tests, and tools tests
• Proper use of @AclValidator for authorization
• DeleteConsumerOffsetRequestHeader has appropriate @CFNotNull annotations
• Admin tool properly handles the new command

---

Automated review by github-manager-bot

[RockteMQ-AI]

Review by github-manager-bot

Summary

Adds a new DELETE_CONSUMER_OFFSET request code and corresponding removeOffset(group, topic) method, allowing deletion of consumer offsets for a specific group+topic combination (rather than the existing group-only deletion).

Findings

[Info] Correctness — The new removeOffset(group, topic) correctly constructs the topicAtGroup key using TOPIC_GROUP_SEPARATOR and removes from all three maps (offsetTable, resetOffsetTable, pullOffsetTable), consistent with the existing removeOffset(group) method.

[Info] Input validation — AdminBrokerProcessor.deleteConsumerOffset() validates that both consumerGroup and topic are non-blank before proceeding, and returns INVALID_PARAMETER with a clear remark.

[Info] Tests — The new removeOffsetByGroupAndTopicTest verifies that offsets for the specified topic+group are removed while offsets for other topics remain intact. Good coverage.

[Warning] Protocol compatibility — This adds a new RequestCode.DELETE_CONSUMER_OFFSET and a new DeleteConsumerOffsetRequestHeader. If a newer client talks to an older Broker that doesn't recognize this request code, it will get a REQUEST_CODE_NOT_SUPPORTED response. This is expected behavior but should be documented.

[Warning] Audit trail — The deleteConsumerOffset method logs the caller address, group, and topic. Consider also logging the previous offset values before deletion for audit/debugging purposes.

Suggestions

• Consider adding an mqadmin subcommand (e.g., deleteOffset) to expose this functionality to operators.
• The removeConsumerOffset(topicAtGroup) call in the new method — verify this triggers any necessary downstream cleanup (e.g., notifying other Brokers in a cluster).

---

Automated review by github-manager-bot