feat(framework,actuator,common): replace fastjson with jackson

[halibobo1205]

Summary

Replace com.alibaba:fastjson with Jackson-backed drop-in wrappers (org.tron.json.{JSON, JSONObject, JSONArray, JSONException}). No external API changes — all HTTP and JSON-RPC responses remain identical.

Motivation

• Fastjson 1.2.83 is EOL with 20+ CVEs including critical RCE
• Upgrade jackson-databind 2.18.3 → 2.18.6 (GHSA-72hv-8253-57qq)
• Unify JSON handling (previously split between Jackson and Fastjson)

Core changes

(common):

• Add org.tron.json wrappers backed by a shared ObjectMapper
• Remove fastjson from common/build.gradle
• Expose maxNestingDepth / maxTokenCount on CommonParameter and NodeConfig.HttpConfig, with defaults 100 / 100_000 in reference.conf

(framework): HTTP & servlet changes

• Swap imports from com.alibaba.fastjson → org.tron.json across all HTTP servlets, JSON-RPC layer, and event/log parsers

Configuration

Two new node.http keys (defaults shown):

node {
  http {
    maxNestingDepth = 100      # Jackson default 1000
    maxTokenCount   = 100000   # Jackson default Long.MAX_VALUE
  }
}

Beyond either ceiling, parsing fails with StreamConstraintsException before any business logic runs. Defaults are sized to comfortably accommodate every legitimate java-tron HTTP payload.

Build:

• Update Jackson to 2.18.6
• Remove fastjson

close #6607

[yanghang8612]

Direction is right — fastjson 1.2.83 has been a long-standing security overhang, and consolidating on Jackson + a thin wrapper is the obvious move. Waiting on the MUST items @lxcmyf and @waynercheung raised before LGTM.

One additional question worth pinning down in the PR description: after this change, are there any remaining com.alibaba.fastjson imports reachable anywhere in the tree — or does this fully retire the dependency? The diff summary doesn't show the build.gradle side, and a grep -r 'com.alibaba.fastjson' --include='*.java' result in the PR body would make the "no more fastjson" claim explicit and let dependency scanners (GHSA, Snyk) close the finding cleanly.

Also worth a sentence in the PR description on hot-path performance posture: fastjson 1.2.x has a historically-fast parse path, and Jackson has different characteristics under LargeJsonPayload + /wallet/* throughput. If there's even a rough benchmark for DeployContractServlet / TriggerSmartContractServlet JSON-decode latency pre/post, that closes the loop on "drop-in" covering both correctness and perf.

[halibobo1205]

@yanghang8612
Fastjson fully retired:
Yes. The fastjson dependency has been removed from build.gradle (diff). If any com.alibaba.fastjson import remained, the build would fail at compile time — so a passing CI already proves zero remaining references.

Performance:
The JSON parsing hot path for /wallet/* endpoints goes through JsonFormat.java (a custom protobuf-to-JSON serializer/parser with its own Tokenizer), not through the Jackson ObjectMapper. Jackson is only used for lightweight operations: extracting a few fields (visible, type, value, etc.) from the top-level request JSON. The actual heavy lifting — protobuf message construction and field-by-field parsing — is handled by JsonFormat.merge(), which is unchanged in this PR. So there is no meaningful parse-latency delta on the hot path. Performance benchmarks will be added as a follow-up.