[Feature] Support Lite Simple Consumer on server side

[f1amingo]

Is Your Feature Request Related to a Problem?

Currently, RocketMQ Lite Topic only supports the Lite Push Consumer model. However, some use cases require a pull-based consumption pattern (Simple Consumer) for Lite Topics, which is not yet supported on the server side.

Describe the Solution You Would Like

Add server-side support for Lite Simple Consumer, including:

1. Broker: Extend NotificationProcessor with a dedicated PopLiteLongPollingService so lite consumers can use the notification (long-polling) protocol. LiteEventDispatcher now also wakes up the notification-side polling service, and exposes a hasEvents(clientId) API for message-availability checks.
2. Proxy: Unify the lite and normal pop-message paths into a single popMessage call, routing internally based on ProxyContext.isLiteConsumer(). Register LITE_SIMPLE_CONSUMER in all client lifecycle switch statements (ClientActivity, GrpcClientSettingsManager). Pass lite-topic property only for lite consumers.
3. Remoting: Add isLiteConsumer and clientId fields to NotificationRequestHeader so the broker can distinguish lite consumer notification requests.

Describe Alternatives You Have Considered

Keeping a separate popLiteMessage API in the proxy layer, but this duplicates code paths and increases maintenance cost.

Additional Context

This change is purely additive and backward-compatible — existing Pop/Push/Simple consumers are unaffected.

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Thank you for the detailed feature request. Here is the assessment:

Feasibility: Feasible — the proposed changes are well-scoped and follow existing patterns in the codebase.

Scope:

• Broker: Extending NotificationProcessor with PopLiteLongPollingService aligns with the existing long-polling architecture for lite consumers.
• Proxy: Unifying popMessage with internal routing via ProxyContext.isLiteConsumer() reduces code duplication compared to maintaining separate API paths.
• Remoting: Adding isLiteConsumer and clientId to NotificationRequestHeader is a minimal, backward-compatible protocol extension.

Compatibility: The change is purely additive as described — existing Pop/Push/Simple consumers should remain unaffected. The NotificationRequestHeader extension with new fields is safe for wire compatibility as long as older clients ignore unknown fields (standard protobuf/gRPC behavior).

Considerations:

1. Are there any edge cases around hasEvents(clientId) when a client switches between lite and normal consumption modes?
2. Should the LITE_SIMPLE_CONSUMER registration in ClientActivity / GrpcClientSettingsManager include migration logic for rolling upgrades where some proxy instances may not yet recognize the new type?
3. Will corresponding changes be needed in apache/rocketmq-clients for the Simple Consumer SDK to use this server-side support?

Overall, this is a well-structured proposal with clear component-level breakdown.

---

Automated evaluation by RockteMQ-AI