feat(http): treat null JsonFormat fields as absent

[halibobo1205]

1. Treat known protobuf fields with literal null as absent so HTTP APIs recover the 4.8.1 fastjson-compatible behavior for null object fields.

2. This relaxes JSON-RPC buildTransaction ABI handling because that path now accepts null ABI fields instead of returning invalid abi.

3. Existing array-element behavior is unchanged: null elements in repeated message/object arrays remain invalid, while null elements in repeated primitive/bytes/enum arrays are consumed and skipped by the legacy parser.
   fix: [Feature] Replace fastjson with Jackson #6607 (comment)

[Sunny6889]

Nice fix on the inbound side. One gap worth a follow-up: this only covers the inbound (parse) side. The
outbound (serialize) side still emits "field":null — org.tron.json's toJSONString() serializes null fields as "field":null, because@JsonInclude(NON_NULL) applies to POJO serialization only, not toJsonNode/tree-model serialization (NullNode is written as-is).

It's functionally fine now (the parser tolerates null), but the response JSON shape still diverges from the old fastjson behavior: fastjson omitted null-valued fields by default, whereas the current output keeps them. Downstream tools that migrated assuming "fastjson omits nulls" will see extra"field":null` entries in node responses.

To fully restore fastjson output compatibility, we'd also need to strip NullNode on the org.tron.json serialization side (prune null object fields before writeValueAsString).

[halibobo1205]

@Sunny6889
Good point in general: JsonInclude.NON_NULL does not prune NullNode values from Jackson tree nodes.

That said, in the current HTTP response paths, I did not find a production path that inserts NullNode into org.tron.json.JSONObject, or parses arbitrary explicit-null JSON and returns it directly. Most outbound JSONObject usage wraps JsonFormat.printToString(proto, ...), and that printer does not emit JSON null fields. Also, JSONObject.put(key, null) removes the key.

So I agree this is a valid compatibility caveat for the wrapper. However, I would treat it as a follow-up compatibility-hardening item rather than a blocker for this inbound JsonFormat fix.

[waynercheung]

LGTM