eth_getLogs: slow responses if the range is not present on the node

[AlexeyKrasnoperov]

Describe the bug

Description of the issue by Ales:

Hey! Spotted another difference in behavior between Forest and Lotus.
Test request ( the range is not present on the node):

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_getLogs",
  "params": [
    {
      "fromBlock": "0x53b79b",
      "toBlock": "0x53b93e"
    }
  ]
}

Lotus responds in less than a sec with the following:

{
    "error": {
        "code": 1,
        "message": "failed to get events for filter: failed to get events for filter from chain indexer: not found in index"
    },
    "id": 1,
    "jsonrpc": "2.0"
}

Forest on the other hands does not respond in 60 seconds before the client timeouts.

Another request (for 2k latest tipsets):

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_getLogs",
  "params": [
    {
      "fromBlock": "0x53EC8D",
      "toBlock": "0x53F45D"
    }
  ]
}

Lotus responds in less than a sec with the following:

{
    "error": {
        "code": 1,
        "message": "failed to get events for filter: failed to get events for filter from chain indexer: failed to get events: filter matches too many events, try a more restricted filter"
    },
    "id": 1,
    "jsonrpc": "2.0"
}

Forest on the other hand takes 24 sec to respond with basically the same:

{
    "jsonrpc": "2.0",
    "id": 1,
    "error": {
        "code": -32603,
        "message": "filter matches too many events, try a more restricted filter"
    }
}

To reproduce

Explained above

Expected behaviour

Just responding with something like “I do not have those blocks” quick enough.

[LesnyRumcajs]

This is a larger undertaking and won't be a quick fix; we'll likely need a relational DB in place. To be properly scoped and planned.