Implement the check_value() method of sMVBA protocol, which verifies the pi proof to ensure no party committed the block of leader in the previous view.

During one epoch reaching for consensus, Core struct uses votes_aggregators to store votes collected from each phase, which should be removed after halting from this epoch.

Ref: https://github.com/guozhengxuan/fsMVBA/blob/7f8ecd672cfefdd35a050c401636df4ddec9124f/consensus/src/core.rs#LL58C6-L58C6
When core receives messages of n-f all No Votes, it's going to reuse the block it proposed in current round as next-round block, which will be achieved by invoke self.get_block(&digest). For syncrony, get_block() happens after store_block(&digest) gets done, which requires implementing another customized future.

Payload communication is isolated from the consensus of blocks. When generating a new block, the consensus Core will grab some new payloads by mempool_driver, which is actually done by mempool core. Meantime, the mempool core broadcasts all these new payloads to other nodes.

Before some node receives a block, the consensus requires all new payloads inside it are received to start any step progressing consensus.

A rough implementation is to discard the Val message if the node does not receive all payloads the inside block holds. To restart processing this Val, the node needs to send some retry message to let the dealer of Val send it back.

Block contains Proof enum, which is either Pi or Sigma. Let core take over control of pi proof, otherwise this issue may occur:
When collecting n-f all No Votes but the node itself has received the leader's block in the second PB, which means the block struct now has a Sigma proof, this causes lost of the original Pi proof in the first PB. Then there is no way to update the original Pi proof by pushing into a new proof pair into it.