finality: Merkle tree based public randomness commitment

[SebastianElvis]

Closes #647

This PR implements the Merkle tree based public randomness commitment. This includes

• reintroduce public randomness storage, message handlers and queries
• introduce a new KV store for public randomness commitment (i.e., Merkle root and other metadata)
• revising the semantics of MsgCommitPubRandList to commit a Merkle root rather than a list of public randomness
• revising the semantics of MsgAddFinalitySig to further verify Merkle proof w.r.t. the public randomness
• fuzz/e2e tests

Future works in subsequent PRs

• remove storage for public randomness: slashing happens upon a double vote in MsgAddFinalitySig. Since MsgAddFinalitySig already contains the public randomness, we don't need to save them in KV store for slashing. We could consider removing it. UPDATE: done in this PR
• alllow out-of-order commitment: in this PR, if a fp commits public randomness that is earlier than the last commit, then it will be rejected. Although out of order commitment seems irrational, maybe we should allow it in case of some unfortunate scenarios? UPDATE: don't do this unless it becomoes necessary
• BTC timestamping of public randomness
• Optimising Merkle proof verification, e.g., using pollarding

[SebastianElvis]

Thanks guys for the comments! I have addressed all of them, most notably verifying proof index and removing public randomness storage. Please take a look again

[SebastianElvis]

One final note, I noticed that we store in state only half of the signature:

FinalitySig *github_com_babylonchain_babylon_types.SchnorrEOTSSig 

and I somehow though we store whole thine ie (R, s), thats why i was in favour of not storing R separately. I have a feeling, that it would be beneficial to store whole thing as otherwise other consumers do not have possibility of verifying those halfs. Not for this pr, but something to keep in mind.

Good point. Actually this is a reason why we should keep the pub rand storage. I added the pub rand storage back for this scenario in case a consumer wants to prove BTC staking finality to others.