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 200 / 30, matching Netty's HTTP/2 server defaults. 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): read and validate the two values before allocating the RPC executor, then always call maxRstFramesPerWindow(...).
• 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 fails fast on invalid input.

This PR has been tested by:

• Unit Tests
  • NodeConfigTest: default resolves to 200/30; 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); invalid runtime values are rejected before the RPC executor is allocated.
  • All 170 tests in the five selected configuration and RPC test classes passed, 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.