JSON-RPC method eth_getLogs improperly interprets block arguments

[mbaxter]

Description

Besu's implementation of eth_getLogs accepts a "blockParameter" for the fromBlock and toBlock values where the block parameter can be a number or a special string ("latest", "earliest", or "pending"). If a string parameter is provided, it is ignored and is instead replaced with the latest block (in the case of the toBlock parameter) or the earliest block (in the case of the fromBlock parameter). This is a bug - if I request blocks from "latest" to "latest", I would expect to get logs from the latest block, but I instead initiate a query for all logs across the entire history of the chain.

Additionally, the JSON-RPC spec documentation only mentions numeric values for the fromBlock and toBlock parameters. So, the API should most likely be throwing an error if a string value is given. However, if besu is going to have expanded functionality and accept string parameters, they should be interpreted correctly.

As a general protection, it's probably a good idea to return an error if the range of blocks requested is too large. An optional upperbound parameter (--rpc-logs-range-upper-bound?) could be added to enforce this.

Acceptance Criteria

• Besu does not interpret requests to eth_getLogs from "latest" to "latest" as a query across the entire range of all blocks

[frankisawesome]

Unless this is a priority issue I'm interested in taking this (turn around will be a bit longer since this will be part time for me)

[non-fungible-nelson]

@frankisawesome this is great! Let me know if we can assist.

[non-fungible-nelson]

@mark-terry is this related to #4443?