[ETCM-969] simple Branch implementation

[AurelienRichez]

Description

This PR creates a simple BlockchainBranch (name up for discussion). The goal is to create an immutable view of a specific branch. Currently it only works for the canonical branch, but the goal would be to have an unified representation for any branch we might want to use and allow to easily switch between branches.

For instance, instead of calling blockchainReader.getBlockByNumber(nb) we would call blockchainReader.getBestBranch().getBlockByNumber(nb)

Important Changes Introduced

the interface BlockchainBranch is the biggest change. At the end it will contain every methods which only make sense in the context of a specific branch (mostly those which need a block number).

This implementation has a few drawback currently though :

• Initially I created getBestBranch in BlockchainReader with a BlockchainBranch because I figured that we should always at least have the genesis block (so at worst the best branch is just the genesis block). However this is not the case in the tests so I have to return an option which makes the interface cumbersome to use. I think it would be worthwhile to actually enforce this in order to have a more elegant interface.
• The implementation might lead to a little more database access because getBestBranch is roughly equivalent to getBestBlock because a BlockchainBranch is defined by its tip and contains the block header. So for instance it would mean that to call isInchain we would get the tip and then check that a given block is in the right branch. This could probably be done without fetching the tip. I think this might be ok as the best block header can easily be cached if it becomes a problem

I had to change lots of tests for this to work. The problem is that lots of tests wrote a block in the storages but did not update the best block. As a consequence, the getBestBranch method does not return the actual best branch in the unit test. I
changed the test to maintain consistency but I am not really sure that it is a good solution.

See #1044 for an improvement on the Option return value

[AurelienRichez]

This is some additionnal logic compared to what was existing. The rationale is that if we want a branch to be an immutable view, then I have to avoid fetching block "in the future" compared to the selected tip.

This is still not perfect because if the number -> block hash index is rewritten, then the interface is not really immutable. The problem should not be apparent unless the instance is used for too long.

[leo-bogastry]

As mentioned in our discusssion, I'm hoping that this method will be part of Consensus soon

[AnastasiiaL]

is it gonna be used only for the main chain? or we could be interested in alternative branches?

[AurelienRichez]

The intent is to be able to use it for other chains as well. So the interface itself does not make any assumption that we are indeed using the best chain.

[AnastasiiaL]

then maybe just Branch as a name will suit better, that'd be my choice

[AurelienRichez]

OK. Let's go for it for now. This part is still heavily changing right now so we will see how this pans out.