feat(jsonrpc): add "input" as field for transaction input

[simbadMarino]

What does this PR do?
Adds "input" field for transaction input while keeping "data" for legacy and compatibility.

Impacted JSON-RPC API methods:

• eth_call
• eth_estimateGas
• buildTransaction

Why are these changes required?

• Align TRON jsonrpc with EVM new standard .
• Reduce development efforts for ETH/EVM developers porting their projects to TRON.
• General EVM tooling compatibility improvements

This PR has been tested by:

• Unit Tests
• Manual Testing

Follow up

• Probably will need to check further simple improvements like this to increase TRON compatibility with eth json RPC

Extra details

• Additional discussions within Foundry devs community: Using multicall with Tron chain alloy-rs/alloy#2371

[0xbigapple]

Good job! Maybe this pr can be added in the next version, along with some other related interface changes. The features for release 4.8.1 are already close to being ready, and I think it may be too late to include this in this version.

[lvs0075]

This feature has been included in the discussions for version 4.8.2

[waynercheung]

The new input support is validated with paramStringIsNull(...), but later resolved with StringUtils.isNotEmpty(...) in getTransactionData().

Those are not equivalent in this codebase because paramStringIsNull("0x") == true, while StringUtils.isNotEmpty("0x") == true.

That creates an inconsistent flow where the request can be validated based on data, but then executed using input, silently discarding the actual calldata / bytecode.

Concrete example:

• to == null
• input == "0x"
• data == "0x6080..."

Please use one canonical transaction-data resolver and one emptiness definition everywhere.

[waynercheung]

The input > data priority is correct, but the conflict case is still undefined.

If both input and data are provided with different values, the current implementation silently prefers input. That makes caller mistakes hard to detect and diverges from geth, which rejects the request explicitly.

Please add a shared conflict check for:

• both fields present
• both non-empty under the project's own null/empty rules
• values not equal

and return a clear params error instead of silently swallowing one side.

[waynercheung]

These helpers(paramTransactionDataIsNull and getTransactionData) look like the intended canonical implementation, but they are not actually used by CallArguments / BuildArguments.

Right now the PR adds a shared utility and still keeps separate local implementations, and those implementations already differ on "0x" semantics. Please either:

• make this utility the single source of truth, or
• remove it

but avoid leaving the refactor half-done.

[waynercheung]

setTransactionData() is currently unused, and its name is broader than its behavior: it only writes data, not input.

That is a maintainability trap for future callers. Please either remove it, or document very explicitly why it only updates data.

[waynercheung]

It has the same problem as BuildArgumentsTest.java:39

[waynercheung]

Thanks for the contribution. The direction is valuable and aligning TRON JSON-RPC with the Ethereum input field is the right goal, but I don’t think this is merge-ready yet.

1. The new input / data handling is internally inconsistent.
   Validation currently uses paramStringIsNull(...), while resolution uses StringUtils.isNotEmpty(...).
   In this codebase those are not equivalent, especially for "0x", so the same request can be validated using one field and executed using the other.

2. Conflict behavior is still undefined.
   When both input and data are provided with different values, the implementation silently prefers input. Please reject that case explicitly with a clear params error rather than dropping one side.

3. Test coverage is insufficient.
   The updated tests only adapt constructor signatures and do not assert the new compatibility behavior. Please add explicit coverage for the supported combinations and the "0x" edge cases.

4. setTransactionData() is unused and misleading as currently implemented.

5. The new helpers in JsonRpcApiUtil are not wired in, so the refactor is left half-done.

6. There are a few minor style issues in CallArguments that should be cleaned up before merge.

Process note
This PR is opened from the fork’s develop branch and currently includes a merge commit from an internal fork PR. That is not a correctness issue by itself, but it makes review scope more mutable and the history noisier than necessary. For follow-up changes, please prefer a dedicated feature branch rebased onto the latest upstream master or develop, and keep the PR branch frozen during review.