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.