Alpha concurrency

..and things get more complicated!

This introduces a parameter to define the set of peers for each slot, in a fashion that all nodes can agree on.  Slot N's peers are defined by the view in force after slot N-alpha.  This has the side-effect of only supporting alpha contiguous slots in play at any time, limiting concurrency.  To help new views take effect quickly, once a view is decided the replicas make alpha no-op proposals.  This also means that replicas need to be pretty aggressive about catching up on previous slots, so that their leader has the history required to work on new proposals.

All of this leads to a pretty massive amount of traffic on a view change: every replica proposes the view change, and eventually one is committed.  That results in a number of no-op proposals which all have to be handled, and during that time there's lots of replicas trying to catch up on the new slots.

Message size and node storage also grow without bound.

I don't think I'll try to fix either of these in the context of the book - the former requires a lot of performance analysis and tweaking of parameters, probably with some randomization; the latter will just require more code and complexity.