Make block generator easier to use

[debris]

let's make it easier to write tests for blockchain

[tomusdrw]

Why not:

let chain_a = genesis.add_blocks(5);
let chain_b = genesis.add_blocks_with_difficulty(9);

let uncle_headers = chain_b[2..4].rev().map(|x| x.last_block_header()).collect();

or

let chain_a = genesis.add_blocks(5);
// with_difficulty clones the builder and changes the default options for all new generated blocks
let chain_b = genesis.with_difficulty(9).add_blocks(5);

[debris]

if you look closely, there are 5 different forks :)

genesis
|      \ 
b1a     b1b
|   \
|    \
|     \
|      \
b2a     b2b
|
....

[debris]

I didn't want to change the logic of a test

[tomusdrw]

IMHO BlockGenerator should not be Iterator, but rather IntoIterator (Maybe even call it BlockChain)

let generator = BlockGenerator::new(&[genesis, first]);
new_chain(&generator[0].data())
// Retrieve iterator
let mut it = generator.iter();

// or consume generator and do sth with blocks
for b in generator {
  ...
}

[tomusdrw]

data is imho too generic. Let's just call it encoded() maybe?

[tomusdrw]

Would rather call it BlockOptions

[tomusdrw]

Imho block is redundant, maybe do this:

blocks.last().number()
blocks.last().hash()
blocks.last().header()
blocks.last().into::<Block>()

[debris]

👍 , if blocks.last() is already a Block, there is no need for into :)

[svyatonik]

Test failure was fixed in master => merged master here

[tomusdrw]

Looks good.
Although imho still would be better to have BlockGenerator behave more like a Vec. Advantages:

1. Can be iterated multiple times (should implement IntoIterator and .iter())
2. No need for funny generator.next().unwrap(), but you rather get nice generator[0] that panics if item is not there.

Actually why not make BlockGenerator::new() just return Vec?

[debris]

I removed usages of generator.next().unwrap() :)