[Nakamoto] Nakamoto p2p block support

[jcnelson]

We need to support Nakamoto block handling in the p2p system in order to unblock a lot of other tasks. This includes:

• Nakamoto block wire format
  • Contains a ConsensusHash that identifies the tenure, and a Vec<NakamotoBlock> for the blocks themselves
  • New StacksMessageID value and StacksMessageType variant
  • New codec for the block message
• Updating stackslib/src/net/chat.rs to handle incoming Nakamoto blocks (but only if the current epoch is epoch 3.0)
  • The block message's consensus hash should be in our burnchain history; otherwise the message is dropped
  • The message needs to count towards that remote peer's bandwidth metering
• Updating NetworkResult to store received and validated Nakamoto blocks, and report that there is data to store
• Updating Relayer::process_network_result() to accept new Nakamoto blocks via Relayer::process_new_nakamoto_block()

[jbencin]

I looked over the code a bit this morning and I think I understand what to do, just want to confirm some things before I get too far:

• For the wire format, we'll need something like the BlocksData struct, but for Nakamoto blocks. I probably shouldn't modify the existing BlocksData though because that would change the wire format, right?
• In general, is it preferable to make existing code accept either StacksBlock or Nakamoto, or leave existing code alone as much as possible, instead copying and modifying it for NakamotoBlock? I'm guessing the later...

cc @jcnelson @kantai

[jcnelson]

For the wire format, we'll need something like the BlocksData struct, but for Nakamoto blocks. I probably shouldn't modify the existing BlocksData though because that would change the wire format, right?

Correct; BlocksData would be a good source of inspiration. Also, we need to keep all existing p2p messages and code paths for now since Nakamoto nodes still need to process epoch 2.x data (including p2p traffic).

In general, is it preferable to make existing code accept either StacksBlock or Nakamoto, or leave existing code alone as much as possible, instead copying and modifying it for NakamotoBlock? I'm guessing the later...

That depends on how functionally similar the Nakamoto versus epoch 2.x code paths are. I'd prefer to see a first draft that has different code paths, and then we can think about consolidation afterwards, so then at least we can all be on the same page as to how similar/different Nakamoto block p2p processing is going to be.

[jcnelson]

@saralab This is still a work in progress