Skip GPM and other checks for transactions whose gas limit exceeds what's left it the block

[oneeman]

Description

This PR implements an optimization to remove a large inefficiency in block creation. The worker goes through, trying to add the transactions in order of decreasing gas price, until it . If it encounters a transaction that requires more gas than is left in the block, it would try to process it and give an error core.ErrGasLimitReached which is then handled by skipping the transaction and continuing trying others (since there may be other transactions later on which require less gas and could fit). The problem was that before this error is returned it does a bunch of work, including core contract calls. This meant that going through transactions which aren't included was taking a long time when the transaction pool had 1000 or more pending transactions.

With this PR, we first check whether the block has enough gas left for the transaction, and if not then we skip right away rather than skipping after getting core.ErrGasLimitReached. Only transactions which would have been skipped anyway are skipped.

This optimization, combined with #1489 and #1467, means the size of the transaction pool will no longer be a bottleneck.

Tested

• Automated tests
• Benchmarking on a single validator-network confirmed that even 8192 pending transactions doesn't slow down block creation.
• Benchmarking on a 100-validator testnet with up to 2000 transactions in the pool confirmed that more transactions in the pool doesn't lead to block creation taking longer as it did before.

Backwards compatibility

No backwards compatibility issues.

[trianglesphere]

I checked the short circuit; LGTM