Add StaticRound to eliminate some boilerplate when writing protocols

[fjarri]

Fixes #65

An experiment to make it possible to write rounds with static message/payload/artifact types. Worth it?

Open questions:

• Should we hide the dynamic Round completely and only expose the static one?
• How will the combinators work in this case? (Misbehave specifically)
• Does this create a confusing distinction between the logic in the rounds (static types) and the logic in the error checking (dynamic types needing deserialization)?

[dvdplm]

I have skimmed the code, so this is not a review.

Thoughts:

• manul is likely never going to be a performance bottleneck
• …so we can "afford" to prioritize readability, ergonomics, correctness and maintainability.
• I think we should make opinionated choices, aiming at giving users one correct way to do what they need to do.

Given the above I think we should provide either dynamic or static rounds, but not both. When we have a concrete use case that requires both dynamic and static we can re-assess.

Is switching to only static rounds possible? It'd be interesting to see how synedrion would look with only static rounds and if there'd be less boilerplate.

[fjarri]

Is switching to only static rounds possible?

For protocols themselves, yes, but evidence verification is not limited to one round and needs access to the message types from the previous rounds - so the user would have to manually transform them from some untyped form to typed messages.

Although it is possible to automate deserialization (and the handling of its errors) - by making every Round type responsible for deserializing its messages and putting them in a Box<>, which the user would later downcast to a specific type. A possible error for this operation is a LocalError.

This would need some kind of "routing" of round number -> boxed round type (not the round object, since we don't need the round state for that). This may be also used to simplify evidence checking for invalid messages (#82).

[coveralls]

Pull Request Test Coverage Report for Build 15745266838

Details

• 169 of 344 (49.13%) changed or added relevant lines in 7 files are covered.
• 28 unchanged lines in 4 files lost coverage.
• Overall coverage decreased (-2.1%) to 70.088%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
manul/src/session/session.rs	0	1	0.0%
manul/src/protocol/boxed_round.rs	9	13	69.23%
manul/src/protocol/static_round.rs	122	138	88.41%
manul/src/protocol/round_info.rs	19	45	42.22%
manul/src/session/evidence.rs	16	54	29.63%
manul/src/combinators/chain.rs	0	90	0.0%

Files with Coverage Reduction	New Missed Lines	%
manul/src/combinators/chain.rs	2	36.75%
manul/src/protocol/boxed_round.rs	6	52.94%
manul/src/protocol/round.rs	7	59.63%
manul/src/session/tokio.rs	13	82.89%

Totals
Change from base Build 15695642792:	-2.1%
Covered Lines:	2315
Relevant Lines:	3303

---

💛 - Coveralls

[fjarri]

Current roadblock: handling protocols where some nodes do not send or do not receive messages (e.g. KeyResharing). This means that the type of the round is not enough to determine whether a message is expected, it's also the state that's needed.

In the n-of-n case the static rounds eliminate the need for verify_*_is_invalid() methods, and also allow one to split evidence checking into per-round methods, making them much easier to maintain.