fix(rpc): apply RST_STREAM frame limit by default

[waynercheung]

What does this PR do?

Turns node.rpc.maxRstStream and node.rpc.secondsPerWindow into properly defaulted and validated options, and applies the gRPC HTTP/2 RST_STREAM frame limit unconditionally.

• common (NodeConfig): default both options to 1000 / 5. In postProcess, reject negative values for either option and reject Integer.MAX_VALUE specifically for maxRstStream (which grpc-java treats as disabling the limit), and independently fall back each 0 to its default with a warning.
• framework (RpcService): always call maxRstFramesPerWindow(...) with the configured values; validation stays solely in NodeConfig, consistent with the neighboring maxConcurrentCallsPerConnection option.
• reference.conf, docs/configuration.md, config/README.md: document the new defaults and the 0 fallback kept for backward compatibility.

Why are these changes required?

Both options previously defaulted to 0, and RpcService configured maxRstFramesPerWindow only when both values were positive. As a result the RST_STREAM frame limit was left unset in a default deployment, and misconfigured values (negative for either option, or maxRstStream == Integer.MAX_VALUE) were accepted silently. This brings the two options in line with how the neighboring maxConcurrentCallsPerConnection option already behaves (a secure default plus validation), so the setting is consistent across the config, cannot be silently disabled, and rejects invalid values at startup.

This PR has been tested by:

• Unit Tests
  • NodeConfigTest: default resolves to 1000/5; each 0 independently falls back to its default; negative values and maxRstStream == Integer.MAX_VALUE are rejected with PARAMETER_INIT; explicit positive values (including Integer.MAX_VALUE - 1 and an Integer.MAX_VALUE window) are preserved.
  • RpcServiceHttp2SecurityTest: the limit is enforced at the connection layer under the default, under the legacy 0/0, and under an explicit small limit; a connection at the limit still gets its PING acknowledged, and one more RST_STREAM past the limit is answered with GOAWAY(ENHANCE_YOUR_CALM).
  • The affected configuration and RPC test classes pass, along with framework Checkstyle and reference.conf validation.
• Manual Testing
  • No separate manual testing; transport behavior is covered by the automated raw HTTP/2 tests above.

Follow up

None.

Extra details

• Backward compatibility: an explicit 0 for either option now falls back to its default (with a startup warning) instead of leaving the limit unset; maxRstStream = 2147483647 (Integer.MAX_VALUE) is rejected at startup. Upgrade notes are included in docs/configuration.md and common/src/main/java/org/tron/core/config/README.md.

[halibobo1205]

[DISCUSS] This bounds RST_STREAM per connection, but not per client. grpc-netty creates a new RstStreamCounter for each connection (NettyServerTransport#L144 → NettyServerHandler#L268-L269) and, on overflow, closes only that connection with ENHANCE_YOUR_CALM "too_many_rststreams" (#L590-L594). The gRPC ports have no per-IP connection cap: there is no ServerTransportFilter and no TLS, maxConnectionsWithSameIp is P2P-only, and RateLimiterInterceptor runs per call, after the stream already exists. A client that reconnects after each GOAWAY therefore keeps much of its stream-creation rate; in a loopback test, reconnecting under 1000/5 still kept more than half of the unlimited rate. The javadoc itself says the setting "can reduce the impact … when combined with TLS and maxConcurrentCallsPerConnection".

This is still a clear improvement and needs no code change here. Could the upgrade note say that a reconnecting client is not bounded, and recommend connection-rate or per-IP limits at the LB/firewall for public gRPC ports? A per-IP gRPC connection cap could go under "Follow up".