Output NetworkInfo from Dynamic Honey Badger

[afck]

This allows the user to use current cryptographic keys and key shares.

An example use case would be if we want to make the sequence of batches
verifiable for third parties, like a blockchain. We would have each
batch signed by the set of validators that produced it, and whenever a
validator changes, sign the new public key using the old key shares.

To a third party that would then look like the owner of the secret key
signed each batch, and occasionally changed their key.

Closes #102

[afck]

This is not a nice solution and I'm open for suggestions! I've thought of three alternatives:

• Adding a netinfo getter instead of outputting it with each batch wouldn't work: It's conceivable that a single call to handle_message produces several batches with key changes, so we would miss one, and be unable to complete the chain of signatures.
• Adding the network info to the Batch itself seems dangerous: I think the batches should be considered the public agreement, i.e. they shouldn't contain a secret key share, and they should be equal in each node.
• Putting the NetworkInfo into an Option and only cloning it when it has actually changed instead of every time seems less wasteful. But it makes the type more complicated, and one clone per batch is negligible overhead.

/cc @c0gent

[c0gent]

It seems like NetworkInfo may be pulling double duty here. Perhaps create a separate, PublicNetworkInfo type that is similar but contains no secret key?

[afck]

That's true, that would make sense anyway, and then we could make the PublicNetworkInfo part of the Batch itself. But what about the private one? That needs to be passed back to the caller after a validator change, too. I guess we'd still have a tuple then?

type Output = (Batch<Tx, NodeUid>, SecretKey);

[c0gent]

You could store it as a struct with three fields then assemble it into a tuple or a two-field struct when needed. I'm not completely clear on the nuances of how this is used though so take my advice with a grain of salt.

[afck]

I'm not completely clear on the nuances of how this is used though

I'm not sure yet either. I'm happy to postpone this until we have a clearer picture of what we need from Parity's side.

[afck]

I'll close this for now. Needs some API design.