fix: OOM when eth_getLogs response too large

[yihuang]

Closes: #858, #861

Description

• add limit to number of logs of filter response
• make block limit and log limit configurable
• fix empty response when specifying blockHash but without address/topics filter critiera.

---

For contributor use:

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer

---

For admin use:

• Added appropriate labels to PR (ex. WIP, R4R, docs, etc)
• Reviewers assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[codecov]

Codecov Report

Merging #860 (ec183af) into main (eb17366) will decrease coverage by 0.06%.
The diff coverage is 20.00%.

@@            Coverage Diff             @@
##             main     #860      +/-   ##
==========================================
- Coverage   56.61%   56.55%   -0.07%     
==========================================
  Files          72       72              
  Lines        6066     6076      +10     
==========================================
+ Hits         3434     3436       +2     
- Misses       2433     2441       +8     
  Partials      199      199              

Impacted Files	Coverage Δ
server/config/config.go	21.05% <20.00%> (-0.08%)	⬇️

[fedekunze]

Can you add a changelog entry too?

[yihuang]

Can you add a changelog entry too?

done

[odeke-em]

Thanks for the fix @yihuang. I've added a comment about a potential overflow that could bypass this change and trigger the OOM.

[odeke-em]

If I still want to trigger an OOM, I can ensure that len(logs) > maxint/2 as well as len(filtered) > maxint/2 which will bypass this check as they'll overflow and become negative in the addition len(logs)+len(filtered). To properly fix this, you mos def want to check arithmetic by subtraction and comparisons individually against len(logs) then len(filtered)

[yihuang]

Since len(logs) <= logLimit and len(filtered) <= block gas limit / gas per log, minimal gas per log is 375, a typical block gas limit is tens of millions, so it's pretty safe even for 32bit int, basically impossible for 64bit int.