Initial draft code for approvals assignments

[burdges]

Initial draft implementation of the approval assignments subsystem described in #1518

In polkadot, we have first backing checks in which some slashable validator commits to a parachain candidate being valid, second availability aka inclusion in which a 2/3rd majority claims the parachain candidate is available, and third approval checks in which random validators check the parachain candidate.

In this PR, we actually assign those individual validators who perform approval checks of available aka included parachain candidates. It's vaguely like some OS task scheduler, well if your CPU cores were adversarial and needed to randomly check one anthers' work.

As explained in #1518 assignments are computed with VRFs using the assignee's secret key, not just some secret system randomness, which gives assignments some meaningful prioritization, called a delay tranche.

We've several priorities here, which include:

• Adversaries must not foresee too many of the assigned checkers, which includes replacing any who became exposed too early due to relay chain equivocations.
• We assign enough checkers maintain confidence and prevent casual attacks using validators that adversaries consider disposable, aka compromised, which includes reducing the adversary's search space.
• We replace slow assignees with more random assignees, since they might be under denial of service attack, but not with so many that a few crap validators makes everyone else overworked.
• All checkers can manage their own work loads without triggering replacement by simply not announcing too many assignments, but more checks per relay chain block ultimately permits more parachains.

There is a lot missing here, but some initial steps:

0. As a part of Initial guide text for approvals and especially approvals assignments  #1518 Rob should decide if approvals and disputes live in the same crate. I think separation looks viable, but disputes must listen to both backing and approval validity votes.

1. There are numerous unimplemented!() calls, mostly in stories.rs and especially on ApprovalContext, but elsewhere too, that import data about relay chain blocks, like their VRFs, included paraids and candidate information, and equivocations. All these should be replaced with appropriate plumbing by someone who actually knows the substrate and polakdot code base (not me).

2. There are a few unimplemented!() calls for accessing the local key store, which someone should fill in. We've zero need for remote signer support here, as assignment keys would not be slashable, not anytime soon anyways, so this should be straightforward for anyone who knows the keystore interface.

3. There are unimplemented!() calls for serialization in criteria.rs I think, which anyone here except me could figure out quickly probably. I've actually outright omitted most serialization work here, which we can discuss in the channel. We should avoid exposing too many implementation details from assignments, which becomes easier to achieve once serialization work starts. Also, we've a wider discussion about gossip, politeness, etc. but that's mostly for follow ups to Initial guide text for approvals and especially approvals assignments  #1518 not here.

4. I've omitted any tests here because the 1-3 must happen first.

5. I kinda (ab)used dyn here for simplicity in this first draft, but enum SomeCriteria looks helpful not just for serialization, but maybe for annoucer.rs too.

6. I've omitted entirely the announcement postponement decision system, but I designed the current data structures with announcement postponement in mind. It's important that postponement happens before announcement, but I've no opinion about whether this happens via separate routines or parameters to the announcement routine.

7. I've avoided doing the on-chain approval checker. We could just store all the gossip messages on-chain and process them in one batch in some future relay chain block that claims its ancestor is now approved. We could add separate on-chain types that impl Criteria but check and strip the VRFs signatures when inserted into the state, and thus reduce state usage.

8. We rescan some data structures here in ways that seems (a) inefficient if done on-chain, but maybe it'll only ever be done once on chain, not sure yet, and (b) risky against denial-of-services, but our usage of VRFs prevents too much spam. It's still maybe worth optimizing, provided we avoid risks from code complexity.

9. In the vein of 8, I've opted for a more complex assignee counting and approval determination system, which keeps our assignment types down to just three, and keeps the stories being only about the relay chain VRF and equivocations. We could however simplify this system by adding a third NoShow story type about another announcement, and adding fourth criteria that assigns and announces this. I suppose this somewhat simplifies the data structures in 7 too, but the total complexity sounds higher.

10. We could merge our announcements in one tranche, which improves VRF signature verification time and slightly improves our gossip, but complicates the code somewhat. I abandoned this optimization because 40ms * num_validators sounds small-ish compared with the cost of even one validator checking a whole block, but..

11. I still need to go through this and retune all the miriad parameters, and chat with Alistair, Handan, etc. about them. Yet, they also require explanation, so feel free to discuss them here too.
    "We go to 11" -- This Is Spinal Tap ;)

In short, can folks try to fill in the unimplemented!() calls in this?

[cla-bot-2020]

@burdges it looks like you have not signed our contributor license aggreement yet. Please visit this link to sign our agreement. This pull request cannot be merged until the agrement is signed.

[cla-bot-2020]

@burdges, Your signature has been received.

[burdges]

@rphmeier We could largely divorce this code from the chain like grandpa, and remove most unimplemented!(), by making ApprovalContext in stories.rs actually refer to the Tracker. You'd then add each included candidate to the tracker manually when creating one. It might simplify using this from both the chain and in a consensus protocol.

[burdges]

We should split tracker.rs into an independent implementation of the counting algorithm, and a separate implementation of its database. We can then adapt the stories.rs, criteria.rs, and the counting algorithm for actual use, and someone can reimplement all the data storage logic twice, once for on-chain and once for off-chain.

[burdges]

Superseded by #2112