fix: handle mixed range getLogs query with dedups

[haardikk21]

Having a getLogs request with fromBlock = latest and toBlock = pending will occasionally error out saying {"jsonrpc":"2.0","error":{"code":-32602,"message":"invalid block range params"},"id":42}

It has to do with the fact that if toBlock = pending, we attempt to do the following:

1. Get the canonical block number from the pending state (i.e. full block on top of which all pending state is being built)
2. Fetch logs from underlying ETH API for fromBlock to canonBlock
3. Fetch logs from pending state
4. Combine the two

The problem is in the second step here. If fromBlock = latest, it's possible that latest > canonBlock due to the ordering of how messages are being processed by the pending state processor. Basically if the state processor gets a flashblock notif before it gets a full block notif, it will continue to keep that state in pending right now. So it's canon block number will fall behind underlying ETH API latest block number. This causes an invalid block range params error

The new approach:

1. fetch logs from the underlying ETH API for fromBlock to latest
2. fetch pending logs
3. deduplicate logs on (block_number, log_index)
4. combine and return