Get a basic object diffusion working

[Niols]

[tbagrel1]

Object diffusion mini-protocol is being developed in https://github.com/IntersectMBO/ouroboros-network/tree/peras%2Fobject-diffusion.

At the moment, most of the code has been copied and adapted from TX submission. For peras certificate diffusion, we need a client-inbound polarity (the opposite of TX submission), as the client requests the certificates, and they get sent by the server. Leaf nodes, which are operating in client-only mode, will never have any certificates to send upstream, unlike transmissions.

On the other hand, future peras vote diffusion will need client-outbound polarity (same as transactions).

In that context, @Niols and I tried to generalize ObjectDiffusion to work with either client-inbound or client-outbound polarities. This attempt is available here. However, we faced many challenges, and decided to give up for now.

Indeed, most of the TX submission code (that we started from) relies on clearly identified client/server roles, and assumes that the client is inbound and server is outbound. It relies heavily on definitions from Network.TypedProtocol.Peer.{Client,Server} from typed-protocols, in which the two roles are clearly distinguished.

typed-protocols also provides a more general module Network.TypedProtocol.Peer, in which the client/server dichotomy isn't present, but instead represented by a type parameter pr :: PeerRole. However, it's not clear what the peer role means exactly. Is it really important to know who initiated the communication (which seems to be the de-facto definition of client/server in the current context), or should we focus instead on who asks and who sends the main data? In which case, the peer role's values would be rather Inbound/Outbound, with an extra parameter being who started the communication (InboundStarted/OutboundStarted).

In the current context, it seems quite expensive to make the object diffusion code work with clearly identified client/server components, but be generic over the polarity (ClientInbound/ClientOutbound), as the polarity is what defines most of the behaviour of the protocol (e.g. a client in ClientInbound and a server in ClientOutbound polarity share almost exactly the same behaviour and internal representation, except when it comes to MsgInit). What could be worth it is to have clearly identified Inbound and Outbound peers, and have ObjectDiffusion be generic over who sends the first message (InboundStarted/OutboundStarted). But that would probably require a large change/refactor in typed-protocols. It seems out of scope for the current feature's development. It's still a bit sad however to need two copies of ObjectDiffusion in the near future (being slightly adapted versions of TX submission, so almost three times the same modules) just to handle the I initiated and push data/I initiated and pull data dichotomy.

For now, the work should continue on https://github.com/IntersectMBO/ouroboros-network/tree/peras%2Fobject-diffusion. Next steps (according to @Niols) are:

• Have a version of ouroboros-network with ObjectDiffusion that compiles fine (with the same agency/polarity as TX submission for now);
• Write basic two-node test scenario and check ObjectDiffusion mini-protocol against it;
• Reverse the agency/polarity to match the one expected for certificate diffusion, and ensure it still passes the tests