`QueueingHoneyBadger` now waits after an output, and only makes its
proposal for the next epoch when:
* there are pending transactions in the queue,
* there are pending key generation or vote messages, or
* _f + 1_ other validators have already made their proposal.
This rule should work well for small networks: With 1 - 3 nodes, it will
produce a new batch whenever at least one of them has transactions to
contribute. In larger networks, it prevents an adversary controlling _f_
nodes from producing lots of empty epochs.
An exception is made for a currently joining validator: We will commit
up to _(N + 1)² + 1_ key generation messages for them, which is the
maximum number a correct node will send.
Random adversaries are created for `broadcast` and `honey_badger`. Random value generation was added for all type-dependencies of these algorithms, causing the `Rand` trait to be implement for a large portion of the codebase.
Additionally, `MessageWithSender` turned into an actual struct, making it much easier to handle. Tuple-like construction is still available through `MessageWithSender::new()`.
* Clear outdated key gen messages from the buffer.
* Process output after proposing, to make `HoneyBadger` work with a
single validator.
* Print an error if threshold decryption fails.
* Verify decryption shares with the correct ciphertext.
* Insert all ciphertexts from an epoch at once; otherwise contributions
can be omitted from a batch.
* Remove `BoolWithFaultLog`: It's easier to return a tuple, and it's
used only in one place now.
* Avoid redundant signature verification in `VoteCounter`.
* Fix the tests for `QueueingHoneyBadger`.
* Use fewer network sizes to speed up tests a bit.
This makes Honey Badger a bit more complicated but a lot more flexible:
It is now unaware of transactions and basically just runs one Subset
instance per epoch.
That way, users can use any kind of external queue, control throttling
and prioritization.