Optimize PrepareRequest construction

[AnnaShaleva]

NeoGo has mechanism that in case of CV allows to fetch some of the known transactions from the previous dBFT view and construct new view PrepareRequest based on these known hashes. It's needed to make it easier for CN to collect necessary set of transactions to approve block: https://github.com/nspcc-dev/neo-go/blob/3176f72878bab11fc824c53e8b24b584971163f7/pkg/consensus/consensus.go#L642-L672.

However, implementing it on Geth is a tricky task because of the current way of dBFT integration with miner. dBFT doesn't create proposal by itself, it waits for the miner's proposal to be accepted, and thus, it can't precisely manage the set of transactions in proposal. So that's the caveat.

Ref. #59.

[AnnaShaleva]

After anti-MEV dBFT extension integration (#287) a set of other fields become useless at PrepareRequest level, in particular, those fields that may be changed in the final Block due to decrypted transactions addition:

• ReceiptHash
• MixDigest
• Merkle root
• Transactions root
• Receipts hash
• Bloom
• may be something else, need to check carefully.

These fields can't be verified by CNs at PrepareRequest level with AMEV logic and hence, they should be removed from PrepareRequest.