refactor(http): improve JsonFormat parser robustness

[halibobo1205]

What does this PR do?

Improves JsonFormat parsing robustness for protobuf JSON used by HTTP wallet APIs.

• Reworks field parsing so comma-separated fields are handled iteratively instead of recursive self-calls.
• Adds nesting-depth checks when parsing object/array structures in JsonFormat.
• Adds unit coverage for preserved parser behavior, changed parser behavior, trailing comma handling, nesting limits, and large flat JSON bodies.

Why are these changes required?

The previous parser could consume an excessive call stack when processing very field-heavy or deeply nested JSON input. This PR makes the parser fail predictably with ParseException for overly deep input, while keeping normal JSON/protobuf parsing behavior compatible.

This PR has been tested by:

• Unit Tests
  • ./gradlew :framework:test --tests org.tron.core.services.http.JsonFormatTest --tests org.tron.core.services.http.TriggerConstantContractServletTest :framework:checkstyleTest -x generateGitProperties
  • ./gradlew lint
• Manual Testing
  • Verified compatibility-sensitive parser behavior before and after the change:
    • Existing unknown-field skipping remains supported.
    • Known repeated fields still reject unsupported nested arrays.
    • Unknown nested object/array fields still reject trailing commas.
    • Valid nesting within Constant.MAX_NESTING_DEPTH remains accepted.

Follow up

None required.

Extra details

Compatibility notes:

• Direct JsonFormat.merge() callers now reject protobuf JSON nesting beyond Constant.MAX_NESTING_DEPTH with ParseException: Hit recursion limit..

• HTTP API compatibility risk is low because the normal HTTP JSON path already applies Jackson's MAX_NESTING_DEPTH = 100.

• Deeply nested invalid input now returns a parser error instead of surfacing as a container-level HTTP 500.

• • JSON-RPC create-contract ABI parsing keeps the previous deeply nested ABI behavior: it still returns invalid params with invalid abi. Other ABI inputs that fail JsonFormat parsing may now also be reported as invalid params instead of internal error; this only affects invalid ABI input.

• Compatibility notes for trailing commas:

Scenario	Example	Before this PR	After this PR	Notes
Top-level object trailing comma	{"address":"61646472657373",}	Rejected with ParseException	Accepted	Behavior is relaxed. This applies to top-level fields after the caller loop consumes the trailing comma.
Known nested message trailing comma	{"genesisBlockId":{"hash":"00","number":1,}}	Rejected with ParseException	Accepted	Behavior is relaxed for known protobuf message fields.
Known repeated field trailing comma	{"approvals":["00","01",]}	Accepted	Accepted	No behavior change; repeated-field array parsing already tolerated a single trailing comma.
Unknown nested object trailing comma	{"zzz":{"a":1,}}	Rejected with ParseException	Rejected with ParseException	No behavior change. Unknown fields are only skipped and are not used by business logic.
Unknown nested array trailing comma	{"zzz":[1,]}	Rejected with ParseException	Rejected with ParseException	No behavior change.
Repeated commas	{"address":"61646472657373",,}	Rejected with ParseException	Rejected with ParseException	No behavior change; only a single trailing comma may be accepted on known/top-level paths.

This is an input-acceptance relaxation for top-level fields and known nested protobuf message fields. It is aligned with the existing org.tron.json.JSON behavior, which already allows a single trailing comma while rejecting repeated commas.

[bladehan1]

Findings: 1 [DISCUSS] (trailing-comma behavior — appears intentional, aligns with the fastjson-compat JSON shim) + 1 [NIT] (boundary test + cosmetic loop shape).