Configurable peers

[ch1bo]

What & Why

Right now, the hydra-node is configured on startup to which other nodes it is connecting to using command line arguments like --peer. This is very inflexible, as it means the hostnames/IP addresses need to be known up-front and this becomes quickly unmanagable, especially in bigger, coordinated setups like benchmarks from #203 or #186.

For that matter, this feature will add ways to modify peers during runtime of hydra-node via the API.

For now, it shall not be possible to change the list of peers while the head is initialized or open. So only in IdleState.

Also, we want to be using the existing API layer to keep this small and focused! (see below for more rationale)

How

• New client inputs and outputs are added for providing a new peer list, e.g. ModifyPeers
• Extend the Network handle to modifyPeers :: ([Peer] -> (a, [Peer])) -> m a
• The head logic will allow modification only when the head is in IdleState
• Modifying the peer list will have the network layer do a full reinitialization
• (optional) Factor a Hydra.NodeLogic module with a similar update function, moving the event/effect types into a shared module, and handle these "node-level" concerns there. For other concerns it would delegate to Hydra.HeadLogic.update

FAQ

• Do we want to keep the command line way of configuring peers? Yes, these would be "starting" peers
• Is it allowed to change peers in all Head states? No, only while in IdleState
• Didn't we want to create an Admin/Operator API (ADR-15)? Yes, but we want to focus on the actual problem at hand. We would need to move other existing things like PeerConnected anyways.

[ch1bo]

We have had a discussion on the configurable peers and while we developed it to a point where we could have merged something like this, the overall UX and goal of the story was not where @abailly and me felt it should be going.

It's a bit sad, but we decided to park this for now. Keep it on a branch, demo it, but not merge and release it on 0.7.0.

Some details on what was lacking in the approach (not the implementation)

• If the connection between two nodes (A and B) is only specified from one direction (e.g. A -> B)

• Node B does see the incoming connection and reports a PeerConnected

• This is exactly the wrong way around, if at all node A should see B connected as messages sent from A would reach B, but not the other way around

• Changing this is not trivial. We drew some things on Miro today (evolved to the drawing below) and no simple / clear solution is evident.
  

• It's complicated to improve because our use of the ouroboros-network and basically treating each connection unidirectional, not really taking advantage of TCP connections.

• We started discussing how we imagine the two peers needing to be configured and realized that it actually does not solve the initial user journey. All nodes need to have connection info of all the other anyways eventually.

• The problem within this is not the non-interactivity: whether to do it via command line, config file or via API makes not much difference. In fact, configuring a process via an API is even more annoying than changing some config its command line.

Concluding, this should tell us a story about being VERY clear on the WHY and the resulting user experience and/or having actual users to talk to along the way.