Make Subset optimization optional

[ErichDonGubler]

Fixes #243. Allow client code to control the behavior of EpochState and when it decides to send decryption shares. There are two options for the behavior for handling the output of a Subset algorithm, which are represented by the new SubsetHandlingStrategy (bikeshedding welcome!) enum:

1. Incremental, which is the current (optimized) behavior.
2. AllAtEnd, which is supposed to be the old behavior. Reviewers crunched for time might want to place priority on making sure I've done this right.

SubsetHandlingStrategy is exposed at the builder level. Internally, an EpochState instance now stores a SubsetHandler enum member that models the necessary state for each different strategy. To resolve ownership issues, I've changed EpochState::{process_decryption,send_decryption_share} to take members of the EpochState struct instead of the entire struct (self). I've also created the finalize_subset_with_step method which also uses members and not self.

Tests compile, but I'm currently blocked on #249 for testing locally until I get home and have access to my *nix machines.

Current concerns

• Bikeshedding on new symbol names?

[afck]

Maybe this could be simplified—and the macros, Self destructuring and static methods avoided—if SubsetHandler had a handle method that takes a SubsetOutput and returns a Vec<SubsetOutput>:

• If it's Incremental, it returns its argument immediately.
• If it's AllAtEnd it stores each Contribution input, and then returns all of them later, when Done arrives.
  We wouldn't need an explicit distinction here, and the code could remain almost unchanged.

[ErichDonGubler]

That makes sense -- I thought about doing that and decided to accept the complexity to avoid heap allocations and copying. You definitely are more familiar with what tradeoffs the codebase needs, though, so I'll make that change once I get to a dev machine.

[afck]

I think that would be premature optimization: The bottleneck in hbbft is on way lower layers (mainly in the cryptography), so our priority should be to keep the code simple.

[ErichDonGubler]

@afck: I've changed the static method/macro binding to be SubsetHandler::handle, like you've suggested -- I have it returning a struct SubsetHandleData that also includes whether or not Done was found, but it essentially follows your suggestion. How does it look?

[ErichDonGubler]

Rebased changes to what has been pulled in today.

[afck]

Looks great!
Let's just make sure everything is documented, in particular public types and methods.

[afck]

Please add a short doc comment explaining subset handling. (Also in HoneyBadgerBuilder.)

[ErichDonGubler]

I noticed I was missing documentation and intended to get to it today -- thank you for reminding me! :)

[ErichDonGubler]

@afck: I've added doc comments written in terms of what I've learned about internals, but would it be better/more user-friendly if they were written in terms of how {Dynamic,}HoneyBadger uses them, instead of referring to algorithms like EpochState and Subset? I'm worried that my lack of domain knowledge doesn't let me write them to be as useful as they could/should be.

That could be saved for a future PR, of course -- just thinking out loud.

[afck]

Looks good to me! The comments are fine; we can add further explanations to them in a separate PR, if needed.
@vkomenda: Feel free to merge if you're happy with it.

[vkomenda]

Looks very good. I like it!
Let's wait for the CI to complete tests. drop_and_readd failed again and I restarted the CI job.