Move block generation to the witness plugin

[sgerbino]

Closes #2717.

[mvandeberg]

You re-created generate_block in the witness plugin, but did not remove it from database

[mvandeberg]

Let's add a method in chain_plugin called, register_block_generator that accepts a function pointer/lambda and we'll call that on a block generate write request. This does not remove the ping pong between the chain and witness plugin on the call stack, but it will remove the source dependency between them. This is the pattern APIs and the jsonrpc plugin use so that the jsonrpc plugin can call APIs without needing to include any information about them during compilation.

[theoreticalbts]

There's a race condition here. The write processing thread is started by chain_plugin::plugin_startup(), which AFAIK because plugins execute in dependency order, occurs before witness_plugin::plugin_startup(). The write processing thread reads the block_generator field once when it starts, it never reads the block generator field again.

I suggest handling this by the following strategy:

• Get rid of the block generator fields in chain_plugin, have it only exist on the write_request_visitor object which is local to the write processing thread
• To get the block generator into the write_request_visitor field, send it as a queue item (i.e., write_request_ptr member type)

It is also tricky to keep races from occurring during shutdown. Can a block production request be in the queue when the witness plugin is destroyed? If it could, then when executing the block production request, it would try to reference a non-existing block_producer, since the block_producer is "owned" by the witness plugin.

I don't think this shutdown race can occur if we only call chain_plugin::generate_block() from witness_plugin::generate_block() . However, I don't think it's good to rely on that.

Fortunately there's a straightforward refactor which will prevent this shutdown race:

• Replace the block_producer_func typedef with a class which has a generate_block() abstract virtual method with the same signature as block_generator_func. Let's call this class abstract_block_producer.
• Instead of passing around block_generator_func*, instead use shared_ptr< abstract_block_producer >.
• Since abstract_block_producer subclasses can be destroyed through a pointer to the base class, abstract_block_producer must define a virtual destructor.

[theoreticalbts]

Turns out the startup race can't occur because the block producer's registered in plugin_initialize, and the thread is started in plugin_startup.

[mvandeberg]

Not merging yet, but lgtm