close #19719

Provided configuration parameters on logs mgt that, when properly tuned
by the service provider, allow the system to avoid being OOM killed:
- --rpc.blockrange.limit (default changed: 0 → 1000): maximum block
range (end - begin) allowed for range queries. The flag already existed
but defaulted to 0 (unlimited), leaving APIs exposed to unbounded block
scans.
- --rpc.logs.maxresults (default: 20000): new flag — maximum number of
logs returned per call. Previously unbounded.

  APIs affected

  Both limits are enforced consistently across:
  - eth_getLogs
  - erigon_getLogs
  - erigon_getLatestLogs
  - overlay_getLogs
  - trace_filter (block range only)

  Behaviour
- Exceeding --rpc.blockrange.limit with an explicit fromBlock/toBlock
range returns an error (query block range exceeds server limit, narrow
your filter: N).
- Exceeding --rpc.logs.maxresults when a query returns too many results
returns an error (query returns too many logs, narrow your filter: N).
- In erigon_getLatestLogs, when the caller explicitly provides logCount
or blockCount that exceed the configured limits, a distinct error is
returned indicating the requested value and the maximum (requested
logCount/blockCount exceeds server limit: requested N, maximum M).
  - Setting either flag to 0 disables the respective limit (unlimited).
- In erigon_getLatestLogs, when the caller explicitly provides logCount
or blockCount, the block range check on fromBlock/toBlock is skipped —
the count-based limit takes precedence.
- The previous hardcoded constants GetLatestLogMaxLogCount (30000) and
GetLatestLogMaxBlockCount (1000) have been removed in favour of the
global config parameters.

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>