Extend handshake parameters

[coot]

Parameters from CodecConfig should be checked in version negotiation:

• EpochSlots
• SecurityParams

Research which other parameters are worth the effort.

[edsko]

Related to IntersectMBO/ouroboros-consensus#649 .

[coot]

Related to #2424, #2425

[mrBliss]

@coot question: why not use the GenesisHash as the network magic (or in addition to it)? That would solve a few of the issues mentioned in the ticket description. It's a bit larger: 32 bytes (Blake2b_256) vs. 4 bytes (NetworkMagic = Word32), but that's nothing.

Even more comprehensive (with IntersectMBO/ouroboros-consensus#649 in mind): compute the hash of the entire TopLevelConfig and use that in the negotiation. That would check all three ticks in the "Across nodes" section of IntersectMBO/ouroboros-consensus#649. Clients won't typically create a TopLevelConfig (just a CodecConfig), so they won't be able to compute the hash of it, but they can just treat it like network magic, which is also a magic constant.

Note that SecurityParam is only in the CodecConfig because it is used to decode things from disk, not to en/decode things from the network. (The plan is to remove it from the CodecConfig.) So it's not strictly needed in the handshake, although we do want both nodes to agree on it.

[coot]

@mrBliss Using hash of TopLevelConfig should be ok, the only requirements we have is that Handshake messages fit into a single tcp segment.

[edsko]

I don't know if it should be part of the handshake, but in IntersectMBO/ouroboros-consensus#649 I was certainly hoping for improved error messages, not just "hash mismatch". We should give a hint about what's wrong, not <hash1> /= <hash2>.

[dcoutts]

For the node-to-client protocol, it'd be nice if we could have the node supply the client with the EpochSlots as part of the handshake. This could eliminate the need to know the EpochSlots up front, which is quite an irritation for clients of the node.