update eth_call error message

[matkt]

PR description

This allows changing the error message during an eth_call by displaying only the error message itself if available, instead of showing the name in the enum. It also makes it possible to display the invalid opcode in case of an invalid operation and more information in case of error (see tests modifications).

Before :
{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"Transaction processing could not be completed due to an exception"}}

After :
{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"Transaction processing could not be completed due to an exception (invalid opcode: 0xaa)"}}

you will be able to see more info after an eth_call:

• Intrinsic gas exceeds gas limit (intrinsic gas cost 21000 exceeds gas limit 0)
• Total blob gas too high (total blob gas 917504 exceeds max blob gas per block 786432)“}
• Upfront cost exceeds account balance (transaction up-front cost 0x2 exceeds transaction sender account balance 0x1)
• etc

Fixed Issue(s)

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

[shemnon]

The changes in the evm module seem orthogonal to this PR. Can they be put in a separate PR? Segregation like this helps immensity when doing "code spelunking" as it removes false-positive rat-holes when bug hunting.

[matkt]

The changes in the evm module seem orthogonal to this PR. Can they be put in a separate PR? Segregation like this helps immensity when doing "code spelunking" as it removes false-positive rat-holes when bug hunting.

The changes to the EVM are necessary for the PR, as they enable displaying the invalid opcode in the eth_call response, which was the initial goal but I can create two PRs if you really think it's better @shemnon ?

[shemnon]

RPC and EVM are uncoupled systems. I would prefer two PRs. Perhaps the RPC changes and then the EVM changes on top of them.