Optimize pending transactions filter

[andresilva]

And make pending transaction count display on ethstats again!

[andresilva]

Fat fingers.

[tomusdrw]

Intentionally changed the behaviour here, returning empty vector when querying e.g. pendingTransactionFilter for logs was weird. I think "Filter not found" is more appropriate response.

[5chdn]

Why is this on ice?

[andresilva]

I opened this PR eagerly by mistake (was just checking this branch with @tomusdrw). I think @tomusdrw is still benchmarking this so it's possible there might be some more changes needed.

(Super dumb, but up until now I though that label meant "oh nice" 😅)

[5chdn]

Oh, nice! 😆

[tomusdrw]

Yeah, sorry about that. I labelled the before after I realised that Andre closed it. I'm done with it now, so it can be left open.

As for the context of the PR:
Currently pending transactions filter is using the very inefficient ready_transactions method from miner. For large pools it takes significant amount of time to construct the pending set, because:

1. We return transactions ordered by priority (gas price)
2. We check for readiness of transactions - i.e. we need to check the state nonce for every sender, and it's really expensive.
   Because of that it can take seconds to construct an ordered pending set of 128k transactions (~110k senders).

The pending transactions filter doesn't require such pending set though, we are ok with unordered hashes and we don't need to be super sure about the nonce, so this PR:

1. Uses unordered transactions from the queue
2. Doesn't use the default Ready (which goes to the state), but rather assumes the transactions in the pool are ready - this may give us a couple of false-positives, but it's not critical for pending transactions hashes.

Thanks to this it works really fast (just constructs the BTreeSet and then does the difference).

[5chdn]

Please assign reviewers yourself. I'm confused about the authorship of this PR :)