[studio] feat: expose gRPC client connection diagnostics in proxy GrpcChannelManager

[btlqql]

[studio] feat: expose gRPC client connection diagnostics in proxy GrpcChannelManager

Relates to #10600 (RocketMQ Studio: AI-Native Management Platform — Track 2: Proxy Admin management capability upgrade).

Background

GrpcChannelManager is the proxy-side source of truth for connected gRPC
clients (clientIdChannelMap) and for pending relay response futures
(resultNonceFutureMap). Until now it exposed no way to observe either,
which makes client connection management and runtime diagnosis impossible for
the Studio management platform and for admin/diagnostic tooling — the exact
capabilities called out by Track 2 of issue #10600 ("client connection
management and runtime diagnostic capabilities").

What this PR does

Adds three read-only, purely additive diagnostic methods to
org.apache.rocketmq.proxy.grpc.v2.channel.GrpcChannelManager:

Method	Purpose
getChannelCount()	Number of active gRPC client channels
getActiveClientIdSet()	Unmodifiable snapshot of connected client ids
getPendingResponseFutureCount()	Number of pending relay response futures

These methods do not alter any gRPC/proto API or protocol contract, so they
respect the Track 2 guideline that protocol/interface changes must be discussed
in an issue first. They are the foundation on which the Studio platform and
admin tooling can build standardized client-connection observation.

Why no protocol change here

Issue #10600 explicitly requires that Track 2 protocol/admin interface changes
be discussed and reach community consensus before code is submitted. This PR
intentionally avoids touching the proxy admin gRPC contract; it only opens up
read-only access to existing in-memory state so it can be consumed later by the
standardized admin layer once that design is agreed upon.

Tests

Adds GrpcChannelManagerTest (extends InitConfigTest, JUnit 4 + Mockito),
mirroring the existing GrpcClientChannelTest, covering:

• Channel create / get / remove and getChannelCount tracking
• Idempotent channel creation (same client id keeps a single channel)
• getActiveClientIdSet() returns an unmodifiable snapshot (independent of
  later channel removal)
• getPendingResponseFutureCount() accounting through
  addResponseFuture / getAndRemoveResponseFuture
• Proper shutdown of the internal scheduled executor in @After

Self-check

• Title is prefixed with [studio]
• Change is limited to a single cohesive concern (2 files)
• No gRPC/proto API or protocol contract is modified (Track 2 discuss-first rule respected)
• Unit tests added for the new behavior

[RockteMQ-AI]

Review by github-manager-bot

Summary

Adds three read-only diagnostic methods to GrpcChannelManager (getChannelCount, getActiveClientIdSet, getPendingResponseFutureCount) to support the RocketMQ Studio Track 2 client connection observability goal. Purely additive, no protocol changes.

Findings

• [Info] GrpcChannelManager.java:83 — getActiveClientIdSet() correctly creates a defensive copy via new HashSet<>(keySet()) before wrapping in unmodifiableSet. Thread-safe snapshot for diagnostic use.
• [Info] GrpcChannelManager.java:77,87 — .size() on ConcurrentHashMap returns a weakly-consistent count, which is appropriate for diagnostics (no locking overhead).
• [Info] GrpcChannelManagerTest.java — Good test coverage: idempotent creation, snapshot independence, unmodifiable enforcement (UnsupportedOperationException), and future accounting. Tests follow existing patterns (InitConfigTest, JUnit 4 + Mockito).

Suggestions

• [Info] Consider adding brief Javadoc to the three new public methods explaining their diagnostic purpose and thread-safety guarantees (weakly-consistent for counts, snapshot for client IDs). This helps future consumers understand the semantics without reading the implementation.

Verdict

Clean, well-tested, purely additive change. LGTM.

---

Automated review by github-manager-bot