Store unknown blocks.

Fascinating bug when the two seed nodes diverged by several thousand blocks
(due to I/O loss, judging from the logs).

When a new block was generated by the remote node, it sends it to us.
We don't know the ->prev_block, so we forget the block, and ask for ->prev_block.
It sends us that block, but again, we don't know prev...

While we're chasing back several thousand blocks, it generates a new block,
and we start chasing prevs for that as well.  Which slows us down more.

Resolving the FIXME and remembering detached blocks should fix this.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Speedup when we attach detached blocks.

Seeking detached blocks before update_block_ptrs_new_block() causes a
massive slowdown because recheck_merkles() runs recursively on all
children.  Switch the order and it's much nicer (though recheck_merkles()
could definitely use some optimization, as the FIXME says).

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Blackbox tests.

As separate from unit tests, these spin up one or more pettycoin instances
and subject them to testing.  First test is syncing after a massive
fork.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
jsonrpc: submitblock command

Great for testing.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Use submitblock for blackbox test.

Instead of waiting for generator.  Runs in about 23 seconds here now.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>