This prevents an edge case where a block downloaded and pruned in-between successive calls to FindNextBlocksToDownload could cause the block to be unnecessarily re-requested.
The issue is that pindexLastCommonBlock is only updated on calls to FindNextBlocksToDownload, by starting at its prior value and then advancing forward until we encounter a block for which we don't HAVE_DATA (which we then try to request).
During initial block download, it's possible for the tip to advance by many blocks during a single call to ActivateBestChain (since blocks arrive out of order, when a block comes in that completes a long sequence, then we'll see many tip updates in a row). If a long enough sequence of tip updates occurs, then it's possible that the block that just arrived could be pruned at the end of processing, before FindNextBlocksToDownload can be called for any other peers. This in turn would cause us to re-request the block from one of those peers, since we'd no longer HAVE_DATA for it.
Since blocks in chainActive never need to be re-downloaded, this
pull should prevent pruning nodes from ever re-requesting blocks in this
situation, while still allowing for pruning nodes to redownload blocks
that may have been previously pruned but are needed for a reorg (this
is exercised in pruning.py, which this pull passes).
