feat: remove block range limit in eth_getLogs when filtering with a single address

[acuarica]

Description:

This PR removes the block range limit, e.g., 1000, when the filter in the eth_getLogs contains a single address (the optional address param might be either a string or an addresses array).

This change allows consumers to query all the log entries of the given address. For now, we permit only a single address, but in the future we might relax this constraint as well.

The block range validation is also used in eth_newFilter, but it should not be affected by this change.

Related issue(s):

Fixes #2175

Notes for reviewer:

It also fixes function type signatures, _i.e., use string[] instead of [string].

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[github-actions]

Tests

    1 files    35 suites   3s ⏱️
194 tests 193 ✔️ 1 💤 0 ❌
197 runs  196 ✔️ 1 💤 0 ❌

Results for commit f341324.

♻️ This comment has been updated with latest results.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.15%. Comparing base (adfe759) to head (f87da1b).
Report is 13 commits behind head on main.

❗ Current head f87da1b differs from pull request most recent head f341324. Consider uploading reports for the commit f341324 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2236   +/-   ##
=======================================
  Coverage   75.15%   75.15%           
=======================================
  Files          13       13           
  Lines         644      644           
  Branches      118      118           
=======================================
  Hits          484      484           
  Misses        115      115           
  Partials       45       45           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Acceptance Tests

  13 files  153 suites   15m 13s ⏱️
398 tests 393 ✔️ 4 💤 1 ❌
418 runs  413 ✔️ 4 💤 1 ❌

Results for commit f341324.

♻️ This comment has been updated with latest results.

[Nana-EC]

LG
1 nit

[acuarica]

@ebadiere @AlfredoG87 I would appreciate your input here if you have some time, thanks!

[AlfredoG87]

Overall looks good, leaved some comments around testing and a question on process.env.TEST that I don't understand, if is a new feature flag it should be documented and use a constant at the top of the class as other feature flags do, and should have a more descriptive name than TEST

2 other questions:

1. should we really allow for unlimited amount of blocks? could it become too much too handle, maybe having a different limit altogether? like maybe, 100,000 blocks or something. let me know your rationale here.
   Have we tested limits on the mirror node for timestamp of query? (`contracts/${MirrorNodeClient.ADDRESS_PLACEHOLDER}/results/logs)

2. On the tests, what happens if we increase the default limit of 1000 to lets say 2000, it would fail?

[sonarcloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[acuarica]

1. should we really allow for unlimited amount of blocks? could it become too much too handle, maybe having a different limit altogether? like maybe, 100,000 blocks or something. let me know your rationale here.
   Have we tested limits on the mirror node for timestamp of query? (`contracts/${MirrorNodeClient.ADDRESS_PLACEHOLDER}/results/logs)

The mirror node supports the query without timestamp. The openrpc.json was updated to reflect pagination limits in f341324.