object diffusion: more client agency for graceful termination, and make server idleness explicit

[prednaz]

Description

Supports IntersectMBO/ouroboros-consensus#2286.

1. Support graceful Object Diffusion termination

introduce MsgServerIdle to regularly return agency to the client from an idle server so the client can gracefully terminate the protocol as needed for tweag/cardano-peras#187

before	after

2. Make Object Diffusion server idleness explicit

split StObjectIds Blocking into 2 states to make idleness of the server explicit so the client can decide if it has caught up or not as needed for tweag/cardano-peras#144

before	after

3. default NoThunks instance for Ouroboros.Network.PerasSupport.PerasSupport

Checklist

Quality

• Commit sequence makes sense and have useful messages, see ref.
• New tests are added and existing tests are updated.
• Self-reviewed the PR.

Maintenance

• Linked an issue or added the PR to the current sprint of ouroboros-network project.
• Added labels.
• Updated changelog files.
• The documentation has been properly updated, see ref.

[tbagrel1]

Looks very good to me! I've only left a couple of syntax/naming nitpicks.

Related note: I don't think the naming convention CanAwait/MustReply for the states is very clear (the message names are fine though). I know it originates from old issues, and I think it was good during prototyping to keep that terminology, but I think it could be a good time now to think about the names a bit more :) Let me know if you have ideas

[tbagrel1]

Similarly here, is there any advantage of having a mega-state with two phases instead of two distinct states?

[prednaz]

OutboundStObjectIds ('StObjectIdsBlocking 'StMustReply) and OutboundStObjectIds ('StObjectIdsBlocking 'StCanAwait) are just as distinct of 2 types as 2 hypothetical types OutboundStObjectIdsBlockingMustReply and OutboundStObjectIdsBlockingCanAwait. so i do not think it is appropriate to associate OutboundStObjectIds ('StObjectIdsBlocking 'StMustReply) and OutboundStObjectIds ('StObjectIdsBlocking 'StCanAwait) with anything else than 2 distinct states.

the advantage of parametric polymorphism is that code that is oblivious to the distinction expressed by the parameter does not have to be duplicated. SendMsgReplyObjectIds 3 lines above is an example. without parametric polymorphism, we would need to duplicate it into SendMsgReplyObjectIdsNonBlocking, SendMsgReplyObjectIdsBlockingMustReply, and SendMsgReplyObjectIdsBlockingCanAwait. a more important example is sendNewContent defined by a user of this library.

[tbagrel1]

the advantage of parametric polymorphism is that code that is oblivious to the distinction expressed by the parameter does not have to be duplicated. SendMsgReplyObjectIds 3 lines above is an example. without parametric polymorphism, we would need to duplicate it into SendMsgReplyObjectIdsNonBlocking, SendMsgReplyObjectIdsBlockingMustReply, and SendMsgReplyObjectIdsBlockingCanAwait. a more important example is sendNewContent defined by a user of this library.

Thanks for the explanation. Would you mind adding this as docstring in the code? Thanks :)

[prednaz]

I don't think the naming convention CanAwait/MustReply for the states is very clear (the message names are fine though). I know it originates from old issues, and I think it was good during prototyping to keep that terminology, but I think it could be a good time now to think about the names a bit more

if it originated from old issues, those were very old issues indeed because ChainSync is using this naming convention too.

ObjectDiffusion	ChainSync (Ouroboros Network Specification)

i suspect that staying consistent with ChainSync might be worth accepting this confusing naming.

[tbagrel1]

Alright, I'm fine with keeping this terminology, as long as we just explain in a comment where it originates from and what it means exactly :)