refactor(config): remove unused storage index and json parsing config

[317787106]

What does this PR do?

Removes two groups of unused or over-engineered config items:

1. node.http.maxNestingDepth / node.http.maxTokenCount — these are JSON-parsing DoS-protection caps that were exposed as user-configurable fields in reference.conf, NodeConfig.HttpConfig, and CommonParameter. Because the values were baked into the JSON / JsonRpcServlet class-level ObjectMapper at first class-load, exposing them as runtime config created a silent initialization-order trap: if any code touched JSON before Args.setParam() completed, the user's overrides would be silently ignored. The values (100 / 100 000) are security constants, not operator-tunable settings. This PR promotes them to Constant.MAX_NESTING_DEPTH / Constant.MAX_TOKEN_COUNT, removes the config binding, and deletes the fragile init-order comment that described the footgun.

2. storage.index.directory / storage.index.switch — legacy config keys that have no consumers in runtime code. Storage.indexDirectory and Storage.indexSwitch were populated from config but never read. The corresponding CLI flags (--storage-index-directory, --storage-index-switch) and StorageConfig.IndexConfig inner class are also removed.

Why are these changes required?

• Removing dead config items reduces cognitive overhead for operators reading reference.conf and for developers maintaining the config-binding pipeline.
• Eliminating the CommonParameter-backed maxNestingDepth/maxTokenCount fields removes a class-initialization ordering constraint that was documented only in a comment, making startup order more robust and the JSON utility class simpler.
• Aligns with the ongoing effort to trim CommonParameter and reference.conf of accumulated legacy fields (part of the feature/reduce_482_config series).

This PR has been tested by:

• Unit Tests (StorageConfigTest, ArgsTest, JsonTest, JsonRpcServletTest updated/passing)
• Existing integration tests that previously passed --storage-index-directory CLI args updated to remove the now-deleted flag

Follow up

Continue auditing CommonParameter and reference.conf for additional unused or redundant config entries.

Extra details

No behaviour change for any running node: the JSON depth/token limits remain exactly 100 / 100 000; index storage was already a no-op.

[barbatos2011]

Removing these @Deprecated CLI flag declarations entirely (not just the underlying binding) is a hard break for any operator whose launch script still uses them. Empirically tested against this PR's build:

$ java -jar FullNode.jar --storage-index-directory /tmp/idx
ERROR [main] [Exit](ExitManager.java:26) Uncaught exception
java.lang.RuntimeException: Invalid inetSocketAddress: "--storage-index-directory",
                                   use ipv4:port or [ipv6]:port
    at org.tron.p2p.utils.NetUtil.parseInetSocketAddress(NetUtil.java:215)
    at org.tron.core.config.args.InetUtil.resolveInetSocketAddressList(InetUtil.java:66)
    at org.tron.core.config.args.Args.applyCLIParams(Args.java:902)
Exit=1

JCommander here is configured without acceptUnknownOptions(true), so it treats unknown flags as positional seedNode arguments. Downstream parsing tries to interpret the flag name as an ipv4:port address and fails. The error message gives an affected operator zero indication that the real problem is "this flag was removed in 4.8.2".

These flags were marked @Deprecated in #6580 (2026-03-26); removal here is ~2 months / roughly one release cycle later — sharp for a release branch where operator scripts are typically expected to keep working.

Three softer options worth considering:

1. Keep the @Parameter declaration but drop only the binding usage in Args.applyCLIParams. JCommander silently consumes the flag, no operator action needed, internal config surface still removed.
2. Pre-parse check that catches these specific flag names and prints a clear actionable error: --storage-index-directory was removed in v4.8.2; please remove from your launch script.
3. Defer hard removal one more release cycle if the project's deprecation policy normally allows two minor releases between @Deprecated and removal.

If the project's stance is "operators must update their scripts when we tag a deprecation" then current code is fine — but it's worth being explicit, because the only signal an affected operator gets on upgrade is the misleading "Invalid inetSocketAddress" stack trace above.