cpuminer: Rework to use bg template generator.

[davecgh]

This requires #2276.

This significantly reworks the CPU miner to make use of the background block template generator that was introduced in the previous release as well as to convert its lifecycle to use the expected pattern for running subsystems based on contexts.

The switch to using the background block template generator provides all the benefits it offers to miners such as:

• Intelligent vote propagation handling
• Improved handling of chain reorganizations necessary when the current tip is unable to obtain enough votes
• Current state synchronization
• Near elimination of stale templates when new blocks and votes are received

This is particularly important in testing scenarios, such as when using the simulation network, since the difficulty is so low that the code this is replacing is often able to mine blocks so fast it ends up mining multiple alternative blocks while waiting for the votes to show up which makes testing with it more difficult.

This is no longer an issue when requesting template updates since the background block template generator has logic to provide the votes a chance to arrive before building and notifying the template.

Another modification this makes is to also make use of template notifications when mining blocks mined via the discrete mining mode and to only count blocks if they successfully extend the main chain. This also significantly helps in testing scenarios since it means the testing code and/or testers using the simulation test network can rely on the requested number of blocks actually being added to the main chain even if more need to be generated to make that happen.

Along similar lines, one area this change does not address, but does pave the way to support and would be useful in the future for the simulation test network is to add some additional logic to provide ticket purchases a chance to arrive when prior to stake validation height, since that is another area that often complicates testing.

In terms of the lifecycle changes, this replaces the Start, Stop, and Wait methods with a single method named Run and arranges for it to block until the provided context is cancelled. This is more flexible for the caller since it can easily turn blocking code into async code while the reverse is not true.

The new Run method waits for all goroutines that it starts to shutdown before returning to help ensure an orderly shutdown.

In addition, the semantics of Run are different from Start/Stop in that the Start method launched the default number of mining worker goroutines whereas Run only starts the CPU miner with the main infrastructure goroutines and zero workers, meaning it will be idle until explicitly requested to mine by the caller setting the number of workers to use.

Since there are exported methods that send messages to the CPU miner infrastructure goroutines via a channel and those goroutines are stopped during the shutdown process, all sends select across both the channel in question as well as a quit channel which is closed when the context is canceled. This ensures callers can't end up blocking on send to a goroutine that is no longer running without needing additional mutexes.

As part of the conversion, it improves a lot of the comments to better describe the expected behavior and further integrates the context to support cancellation where it previously was not supported.

Finally, all callers are updated to use the new API and the server is modified to take advantage of the new lifecycle semantics by taking ownership of the CPU miner code directly in its Run method where it more logically makes sense and only creating the template generate and CPU miner infrastructure if needed based on the configuration options.