fix: use better queries for listLogs endpoint

[zachdaniel]

#1858

Motivation

• The listLogs api endpoint is very slow for moderate-large block ranges. The queries that this PR replaces would take about 500 seconds. These ones still aren't that fast, but they complete in 15-30 seconds for those same block ranges so it is a vast improvement.

Changelog

Bug Fixes

• Use a more optimized query when provided with an address hash filter. We first limit our search to logs from transactions and internal transactions that were from, to, or creating the provided address. This limits the search space significantly.

  • I added an entry to CHANGELOG.md with this PR
  • If I added new functionality, I added tests covering it.
  • If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.
  • I checked whether I should update the docs and did so if necessary

Note: The existing tests reinforce correct behavior, but I can't write a unit test to confirm the performance characteristics.

[coveralls]

Pull Request Test Coverage Report for Build f0131f74-43d6-4030-bfe0-8af47db002df

• 19 of 19 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.04%) to 80.912%

---

Totals
Change from base Build aedde6f0-b477-4623-8632-93b5d7675241:	0.04%
Covered Lines:	4773
Relevant Lines:	5899

---

💛 - Coveralls

[vbaranov]

@zachdaniel

Could you please provide a live example to compare responses between prod/stg where this update gives benefit? Because of an example from the original issue still returns me 504 error on stg.

[pasqu4le]

LGTM, I only have a couple of minor comments

[vbaranov]

Works much faster on stg 👍