Support for reconcile confirmation against the in-memory canonical chain

[Chengxuan]

Requires hyperledger/firefly-transaction-manager#148

This PR introduced a new method, ReconcileConfirmationsForTransaction, which can be used to directly calculate the confirmation map of a given transaction.

The diagram below shows the core logic of the function:

Details of the confirmation Map struct can be found in this PR: hyperledger/firefly-transaction-manager#148

Reconciliation logic for an existing confirmations that get passed in

• If the transaction is in a block hash that hasn't been recorded, that new block hash will be added to the map and a new confirmation queue will be built and stored under that block hash (map key)
• If the transaction is in an existing block hash that's been tracked
  • If any of the existing confirmation block numbers are connectable to any of the block numbers in the current in-memory canonical chain
    • if all of them are chainable (all on the same fork or partially on the same fork), the confirmations on the same fork will be carried over into the new confirmation map, the newFork flag will be set to true in the response accordingly
  • otherwise they are discarded

Confirmation queue for different scenarios:

• In all cases, the first item in the confirmation queue is the tx block (the block that contains the tx).
• In the following scenario, a tx confirmation queue will have a full set of MinimalBlockInfo as the confirmation history
  • all confirmation blocks are in the current in-memory canonical chain
  • existing confirmation queue (provided by the consumer) shares a fork with the current in-memory canonical chain, all confirmation blocks, and:
    • all confirmation blocks are in the existing queue
    • or all confirmation blocks are in the existing queue + the in-memory canonical chain
  • In the following scenario, a tx confirmation queue will have partial confirmation blocks:
    • no existing confirmations provided, some confirmation blocks are ahead of the first item in the in-memory canonical chain.
    • existing confirmation queue shares a fork with current in-memory canonical chain, but it only has partial confirmation blocks in the existing confirmation queue.
  • In the scenario of the target confirmation block number of a transaction is ahead of the in-memory canonical chain or the combined existing confirmation + in-memory canonical chain blocks, the confirmation queue will only have 2 items: the tx block and the head block of the in-memory canonical chain.

[EnriqueL8]

Thanks, looks really good - a few questions and suggestions but thanks for all the comments in the flow

[EnriqueL8]

Are you going to do this figuring out as part of the PR? I did wonder why the TX hash -> block was not a thing

[Chengxuan]

yes, would like to, waiting for @peterbroadhurst 's input

[EnriqueL8]

This function was quite difficult to follow FYI

[Chengxuan]

@EnriqueL8 can you elaborate exactly what's difficult to follow so we can improve it?
e.g. the algorithm used / the comments / variable naming?