Notes on BirthRound in Events

Some notes on adding the `long` field `addressBookRound` to each event.

- The long field addressBookRound is put into each event by the creator of that event. It affects the hash of the event, and so affects the signature of the event. It is immutable.
- The node creating the event X should make this field equal to the most recent round R for which consensus has been reached and all transactions have been handled, as of the moment X is created. NOTE: this guarantees that it is possible to calculate consensus on round R without using this event or any of its descendants. We know it's possible, because the creator actually did it.
- NOTE: we must check that the above step doesn't put a round number that is currently ancient. If the round number calculated above is so old that it's ancient, then do't create an event yet. Because it means there's a backlog of many rounds of consensus events that haven't been handled yet. So wait until the handling has caught up before creating more events, rather than intentionally creating stale events. This check also has the nice side effect that if all the nodes are trying to create events faster than anyone can handle them, then all the nodes will automatically slow down on creating events.
- If the latest fully-handled round yields an address book that doesn't include node C, then C shouldn't create any events. Node C needs to wait until it has actually been added to the address book before it creates any events. And if C used to be in the address book and has now left it, then it also shouldn't create any events (and will soon find itself disconnected from gossip by the other nodes, anyway). If a malicious node violates these checks and creates an event anyway, then it will end up discarded as invalid, so no harm is done, other than a little wasted effort (but not much).
- Each parent of X must have a value for this field that is less than or equal to the value for X. There can never be a parent with a larger value than X. That should be easy to implement, because any event with a larger value should still be in the orphan buffer, because it can't yet be validated. So it couldn't have been a parent, anyway.
- When validating an event received during gossip, check that the creatorId for it actually exists in the address book created by handling the consensus transactions for the round it claims. This implies we can't validate it until we handle all the transactions in the round it claims.
- When recalculating all the events to find the judges for round R, ignore any event which has this field greater than R. (It's guaranteed to still be possible to reach consensus, as noted above). The recalculate method can simply do nothing when passed such an event. It doesn't even need to zero out the arrays.
- When checking whether an event is ancient, treat it as ancient if this field is less than the oldest non-ancient round number. This is just like checking for a too-old generation.
- During gossip, don't validate an event until consensus has been found for the round in its field. Until then, it can live in the orphan buffer (if not too far in the future) or be instantly discarded (if too far in the future). This is just like if its generation is in the future.
- We need to treat an event as round 0 if it is ancient. As we discussed a while back, there are actually 2 ways an event can be ancient. We want to create each event with an address book round number in it, saying which address book was being used when it was created. If the latest consensus round is `R`, then an event is ancient if its generation is less than the min judge generation of round `R-25`, or if its address book round is less than `R-25`.