feat(jsonrpc): add blockTimestamp to logs and receipts

[0xbigapple]

What does this PR do?
Adds the blockTimestamp field to the log objects returned by JSON-RPC event and receipt query interfaces, aligning the TRON JSON-RPC implementation with the Ethereum execution-apis specification. close #6617

Specifically, it updates:

1. LogFilterElement (used in eth_getLogs, eth_getFilterLogs, eth_getFilterChanges(about log/event filter)) to include blockTimestamp.
2. TransactionLog within TransactionReceipt (used in eth_getTransactionReceipt, eth_getBlockReceipts) to include blockTimestamp.

The timestamp is extracted from the corresponding TransactionInfo's blockTimeStamp, divided by 1000 to convert to seconds, and returned as a hexadecimal string (e.g., "0x3e8").

Why are these changes required?
To maintain compatibility with the evolving Ethereum JSON-RPC API standards. Adding the block generation timestamp directly to the log objects enables developers and dApps to process event streams with precise time context without needing to perform secondary eth_getBlockByHash/Number queries, significantly reducing network overhead and improving client efficiency.

This PR has been tested by:

• Unit Tests:
  • Added assertions in LogMatchExactlyTest.java to verify blockTimestamp in LogFilterElement.
  • Added assertions in TransactionReceiptTest.java to verify blockTimestamp in TransactionReceipt.TransactionLog.
• Manual Testing: N/A

Follow up

Extra details

[bladehan1]

See review, comments

[waynercheung]

[SHOULD] The implementation looks good and I’m comfortable approving it. One follow-up I’d still recommend is adding direct API-level coverage for eth_getFilterLogs and eth_getFilterChanges in JsonrpcServiceTest, so the test surface fully matches the public APIs listed in the PR scope.

[0xbigapple]

[SHOULD] The implementation looks good and I’m comfortable approving it. One follow-up I’d still recommend is adding direct API-level coverage for eth_getFilterLogs and eth_getFilterChanges in JsonrpcServiceTest, so the test surface fully matches the public APIs listed in the PR scope.

Thanks for the follow-up. Since eth_getFilterLogs and eth_getFilterChanges share the same underlying code path as this change, the positive-path test on eth_getLogs already covers the shared logic including blockTimestamp validation. Adding full API-level tests for those two endpoints is beyond the scope of this change, as they didn't have tests before this PR either. That said, I think it would be great to have a dedicated tracking issue to cover API-level tests for all JSON-RPC endpoints holistically, not just these two.