core: fix a crash in tx_pool.go when debug.setHead is used

[albrow]

This mirrors a PR to upstream. See ethereum#16713 for more information about the fix. I would suggest we wait for feedback from the Geth team before merging and use the sethead-txpool-fix branch for our development in the meantime.

[fabioberger]

Approving but happy to wait on merging.

[fabioberger]

Comment by @recmo:
"After reading on the problem and the proposed solution I’m left wondering how Geth handles chain re-organizations. In that case you also rewind the chain.
In a re-org you would immediately grow it again with a chain of blocks that is at least as high (due to longest chain fork-choice rule)
But still, pointers to old headers which are now uncles could exist"

[albrow]

@recmo I'm still new to the codebase, but I can take a stab at answering this. It looks like it has something to do with these lines:

rem = pool.chain.GetBlock(oldHead.Hash(), oldHead.Number.Uint64())
add = pool.chain.GetBlock(newHead.Hash(), newHead.Number.Uint64())

For context, oldHead and newHead are block headers which we were tracking in a previous part of the code. I think the purpose of calling pool.chain.GetBlock here is to account for the fact that there could have been a re-org and the blocks we were tracking could have become uncles. But in that case, the blocks still exist in the chain. The reason debug.setHead breaks this is that one of the blocks we were tracking hasn't just moved; it no longer exists. So pool.chain.GetBlock(oldHead.Hash(), oldHead.Number.Uint64()) was returning nil.