feat(api): add peer management to admin RPC

[317787106]

What does this PR do?

Adds runtime peer management to Admin JSON-RPC over HTTP and IPC, so operators can adjust active nodes, inspect connections, and block malicious IPs without restarting FullNode.

The API adds admin_addPeer, admin_removePeer, admin_disconnectPeer, admin_listActivePeers, admin_blockIp, admin_unblockIp, and admin_listBlockedIps. Mutations return a shared PeerOperationResult; active-peer queries reuse the connection, latency, and synchronization statistics used by PeerConnection.log(). The IPC client also supports optional text-table output for admin_listActivePeers.

The five mutating Admin methods emit INFO-level write-attempt logs. Each line records the method and endpoint/IP target; unsafe or overlong targets appear as omitted. The log indicates an attempted call, not a successful mutation.

Why are these changes required?

Operators need to disconnect or block identified malicious peers and add trusted endpoints promptly when investigating degraded connectivity or network isolation. Persistent manual IP blocking keeps those decisions effective across node restarts.

Implementation

This PR builds on the Admin HTTP/IPC framework introduced in upstream PR #6979 and targets release_v4.8.3. It adds peer-management APIs to that framework, together with the supporting behavior and tests in framework and :p2p.

• framework owns Admin HTTP/IPC dispatch, operation coordination, peer statistics, and persistence of normalized IPs and blockedAtMillis timestamps in CommonStore["blocked-ips"].
• p2p provides addActiveNode, removeActiveNode, disconnect, and replaceBlockedIps, plus TCP admission, dialing, candidate filtering, and disconnection enforcement.
• ConnectionPolicy publishes an immutable IP set through a volatile reference and normalizes IPv4-mapped IPv6 addresses for matching. P2pConfig.blockedIps supplies the initial policy; runtime changes update the policy without writing back to startup configuration.
• The independently runnable p2p-standalone.jar retains --blocked-ips / -b. Its argument coverage is consolidated in StartAppArgsTest, and the module README documents startup and runtime usage.

Behavior and compatibility

Active peers

• admin_addPeer adds an endpoint to the active-node set without adding it to trustNodes or waiting for a successful connection. It rejects endpoints whose IP is manually blocked.
• admin_removePeer removes an active endpoint and disconnects its current connection. admin_disconnectPeer disconnects the exact endpoint without removing it from the active-node set, so it may reconnect later.
• admin_listActivePeers reports current connection, latency, and synchronization statistics. Mutations report success, changed, and disconnectedCount, distinguishing a successful no-op from a business failure.
• When node.dynamicConfig.enable is enabled, add/remove operations return a structured failure directing operators to update node.active. The other peer-management operations remain available.

Manual IP blocklist

• admin_blockIp and admin_unblockIp accept IPv4 or IPv6 literals. Repeated blocking is a successful no-op that preserves the original blockedAtMillis timestamp; unblocking an absent IP is also a successful no-op. admin_listBlockedIps returns normalized IPs and their timestamps.
• Persisted blocks are loaded and installed before network initialization. Malformed stored data is deleted on a best-effort basis and the node starts with an empty manual blocklist.
• A blocklist change first installs the p2p policy and closes matching connections, then persists the snapshot, then publishes the framework query snapshot. A persistence failure returns an internal error and leaves the query snapshot unchanged, although the runtime policy may already have changed; retrying the operation reapplies and persists the intended snapshot.

Network scope and compatibility

• Manual blocking applies to TCP connections and dialing candidates. UDP discovery traffic remains outside its scope. FullNode gains no new peer-management configuration switch.
• Connect.proto adds DisconnectReason.REQUESTED = 0x0F for explicit disconnects. The existing disconnect message structure, consensus rules, and chain-data formats remain unchanged.

JSON-RPC behavior

• Public JSON-RPC and Admin JSON-RPC share request-envelope validation through JsonRpcRequestValidator. Admin follows the existing public endpoint: explicit id: null and empty method names are invalid; numeric IDs are not limited to signed 64-bit values; params: null passes envelope validation and reaches method binding.
• Admin continues to reject batch requests. Its five mutating methods emit INFO-level write-attempt logs; a log entry records the requested operation and target, not whether the mutation succeeded.

Testing

Validation on macOS ARM64 / JDK 17 includes:

• ./gradlew clean build -x test and ./gradlew test (full multi-module suite, completed during development)
• ./gradlew :framework:checkstyleMain :framework:checkstyleTest :plugins:checkstyleMain (completed during development)
• check_reference_conf.py, check_reference_comments.py, and check_math_usage.sh (completed during development)
• ./gradlew :framework:test --tests org.tron.core.services.admin.AdminJsonRpcImplTest
• ./gradlew :framework:test --tests org.tron.core.services.admin.ipc.server.AdminJsonRpcRequestTest --tests org.tron.core.services.jsonrpc.JsonRpcServletTest
• ./gradlew :framework:checkstyleMain :framework:checkstyleTest (after the logging and validation changes)

Coverage includes startup policy installation, persistence and corrupt-data recovery, update ordering and retries, idempotency, concurrent mutations, dynamic-config restrictions, IP normalization, and TCP inbound/outbound rejection. HTTP/IPC dispatch, error codes, peer statistics, IPC text output, network lifecycle, and effective-connection compatibility have regression tests. The standalone p2p JAR build and --blocked-ips help invocation were also checked during development.

Open item before upstream submission

Issue #6989 requires audit logging in the shared Admin invocation path before state-changing peer-management methods are submitted upstream. The PR includes method-level logs for invoked write attempts on HTTP and IPC, including notifications that reach the method. These are operational logs, not the complete audit required by the issue: they do not uniformly record transport, caller context, outcomes, JSON-RPC errors, or business failures (success: false), and accepted endpoint/IP targets appear in the logs. The shared-path audit, which must exclude raw parameters, response payloads, credentials, and sensitive paths, remains open before upstream submission.