Limit number of concurrent events that are processed

[fvictorio]

This should fix, or at least improve, the problem described in #64.

The cause of the problem was that making a lot of concurrent estimateGas calls were causing the node to fail (I confirmed this by making a simple contract with a loop and calling it hundreds of times in parallel; let me know if you'd like to see the code). When one of this transactions failed, the whole list of events was discarded. When later the same (or more) events were received, the problem appeared again, and so on.

The fix is to limit the number of concurrent events that are processed (right now to 50). With this fix, we could process a block with 8000 txs without failures.

Doing #63 might have fixed this too, but even with that I think it's a good idea to avoid choking the RPC endpoint. Besides, I'm not 100% sure that #63 would've been enough (if all the retries have the same sucessive delays, each the RPC would be choked again, albeit with less transactions each time).

Some time measurements:

• Signature requests mean time
  • 2000 txs: 25383 ms
  • 4000 txs: 49654 ms
  • 8000 txs: 93609 ms
• Collected signatures mean time
  • 2000 txs: 12939 ms
  • 4000 txs: 22013 ms
  • 8000 txs: 47697 ms

[fvictorio]

Maybe I should also measure the difference between the processing time with and without this change (using a number of transactions that can be handled by the bridge prior to this fix). I'll do that and post the results here.

[rstormsf]

ci is failing

[patitonar]

Perhaps we should run some performance tests to find which is the most efficient value for this. Maybe we can address this in a separate issue.

[akolotov]

Cool! Let's merge this PR. I will create an issue to address this comment: #72 (comment)