[ISSUE #10405] Route orderly retry messages to topic brokers

[btlqql]

Which Issue(s) This PR Fixes

• Fixes [Bug] when orderly consumer consume message fails time reach the maxReconsumeTimes, the %RETRY% topic will create in broker that has not contain the orignial topic #10405

Brief Description

When an orderly consumer reaches maxReconsumeTimes, both the regular and POP orderly services publish the retry message with the default producer. Because the %RETRY% topic may not have publish route data yet, producer fallback can select a broker from TBW102 that does not host the original business topic. This creates retry topics on unrelated brokers and makes retry-topic placement inconsistent with the consumed topic.

This change:

• adds one shared OrderlyRetryMessageSender for both orderly consumption paths;
• resolves a snapshot of the business topic route, including PROPERTY_RETRY_TOPIC when a retry message is consumed again;
• prefers the broker that supplied the original message, then fails over only to other brokers in the business topic route;
• uses a fresh message and property copy for every send attempt so producer mutation cannot leak into later attempts or the consumed message;
• preserves thread interruption and propagates the final targeted-send failure instead of falling back to an unrelated broker;
• retains the previous default-producer behavior only when business topic route data is unavailable.

The change is internal to the orderly retry path and introduces no public API changes.

How Did You Test This Change?

mvn -o -B -ntp -pl client -am -Dtest=OrderlyRetryMessageSenderTest,ConsumeMessageOrderlyServiceTest,ConsumeMessagePopOrderlyServiceTest -Dsurefire.failIfNoSpecifiedTests=false test

Result: BUILD SUCCESS; 27 tests run, 0 failures, 0 errors, 0 skipped. The Maven lifecycle also completed Checkstyle with 0 violations and SpotBugs with 0 findings for the affected reactor modules.

The new tests cover original-broker preference, current-route filtering, cross-broker failover with fresh message copies, retry-message business-topic lookup, unavailable/empty route fallback, refusal to leave a known topic route, and interruption handling.

[RockteMQ-AI]

Review by github-manager-bot

LGTM. Well-designed fix for orderly retry message routing.

Summary

Fixes #10405 by routing orderly retry messages to the original broker first (via RECONSUME_WHEN), with fallback to other brokers on the same topic. Also fixes a property mutation bug by using deepCopyProperties instead of direct reference sharing.

Key Changes

• OrderlyRetryMessageSender — New class that implements smart retry routing: prefers the original broker, falls back to other topic brokers. Thread interruption handling is correct.
• deepCopyProperties — Fixes a subtle bug where clearProperty on the retry message would mutate the original message's properties map (shared reference).
• ConsumeMessagePopOrderlyService — Same deepCopyProperties fix applied consistently.

Positive Notes

• Comprehensive test coverage including edge cases (single broker, all brokers failing, interrupted thread)
• Clean separation of concerns with the new OrderlyRetryMessageSender class
• RETRY_QUEUE_ID = 0 is correct since broker-created retry topics always use queue 0
• Consistent fix applied to both push and pop orderly services

---

Automated review by github-manager-bot