fix: eth_call JSON deserialization when unknown fields use hex encoded string values

[usmansaleem]

PR description

fix: eth_call JSON deserialization when unknown fields use hex encoded string values that caused a runtime exception. JsonCallParameter deserialization logic is changed from @JsonCreator to @JsonDeserialize(builder = JsonCallParameter.JsonCallParameterBuilder.class) by introducing an inner builder. This fixed the issue where the Jackson's default integer to string coercion was applied for unknown parameters in the transaction object in eth_call when they specify hex encoded literals, for example: "unknownField": "0xff".

This fix will allow Besu's eth_call to match Geth's eth_call behaviour to ignore unknown values in the transaction object of eth_call's JSON.

Fixed Issue(s)

fixes #7294

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests

[macfarla]

makes the tests a lot nicer! What testing have you done apart from Besu internal unit tests?
Does this change fix or break any hive tests?

[usmansaleem]

makes the tests a lot nicer! What testing have you done apart from Besu internal unit tests? Does this change fix or break any hive tests?

@macfarla Haven't test with hive tests, however, setting up local testing to deploy a test contract and performs eth_call manually. It should not affect hive test unless hive tests uses extra parameters in an eth_call.

[pinges]

I really like this. Makes tests a lot cleaner. Some comments, just nits

[pinges]

LGTM

[AntonieDavid]

Hey, just letting you know that I've upgraded the linea nodes to the latest besu version (24.7.0) and the gasLimit issue still exists. Similar to what I described in this issue Consensys#41, I am using the same request and getting the same output with "Invalid Params". Have you thoroughly tested this on your side? I'm attaching some detailed info.
`./besu --version
besu/v24.7.0/linux-x86_64/oracle-java-22

curl localhost:8545 -H "Content-Type: application/json" -d '{
"jsonrpc": "2.0",
"method": "eth_call",
"params": [{
"data": "0x535b355c000000000000000000000000cebb9d8349a793439a5f9002934688698783eb740000000000000000000000000000000000000000000000000000f65ad6215c00",
"from": "0xaf8ae6955d07776ab690e565ba6fbc79b8de3a5d",
"to": "0xcf68a2721394dcf5dcf66f6265c1819720f24528",
"gas": "0x15522",
"gasLimit": "0x15522",
"value": "0x0"
}, "latest"],
"id": 1
}'
{"jsonrpc":"2.0","id":1,"error":{"code":-32602,"message":"Invalid params"}}`

[usmansaleem]

@AntonieDavid this PR/commit is not part of 24.7.0. https://github.com/hyperledger/besu/releases/tag/24.7.0 Next release should have this change.

[AntonieDavid]

Oh, got it. Thanks for the clarification. Any ETA for that release? We're waiting on this to take our new besu nodes to production, as they are sidelined for now, because many clients use the typical request format and would be difficult to instruct all.

[fab-10]

After this PR, the gasLimit field is just ignored, is that intentional?

[AntonieDavid]

Yes @fab-10 , it appears it was ignored in geth binary too, so they are just replicating the geth behaviour for besu.