blockchain: Optimize stake node pruning.

[davecgh]

Profiling revealed that the number one cause of allocations in blockchain is currently due to stake node pruning, which definitely should not be the case.

Upon closer examination, the culprit is that every single time the stake nodes are pruned the entire ancestry of nodes prior to the prune height, including those that have already been pruned, are appended to the list of nodes to prune. In practice, this amounts to hundreds of thousands of nodes and thus the slice is resized multiple times (likely around 18 times per run given the current runtime semantics).

This remedies that by ensuring that only the nodes that actually need to be pruned are added to the relevant slice and also preallocating space per a hint that will handle the number of nodes expected to be pruned with a 99% confidence level to further reduce allocations when more than a single node needs to be pruned.

It also renames the slice to reflect what it actually does.

Finally, this renames the field used to track the last pruning time to more accurately reflect its purpose

Relevant portion of the before profile:

github.com/decred/dcrd/blockchain/v3.(*BlockChain).pruneStakeNodes
src\github.com\decred\dcrd\blockchain\chain.go
  Total:    654.60MB   654.60MB (flat, cum) 19.97%
    458            .          .           	var deleteNodes []*blockNode 
    459            .          .           	for node := pruneToNode.parent; node != nil; node = node.parent { 
    460     654.60MB   654.60MB           		deleteNodes = append(deleteNodes, node) 
    461            .          .           	} 
    462            .          .            

It does not even show up in the profile with this PR.

[matheusd]

Thank you for the extended explanation!