Fixing Dynamic Allocation once and for all

[Martin Duke]

Maybe there's a way to fix all the concern with dynamic allocation (#101, #103, #124) in one fell swoop.

1. Leverage the much shorter SCCIDs (thanks Ian) to end the goofy way of extracting a server ID from a 8B CID (i.e. pretending it's plaintext)
2. Simply forbid dynamic SIDs with BCCID (as a precursor to eliminating BCCID altogether -- but that's a different issue)
3. Instead of LBs "learning" SIDs as we go, just require the LB to have some sort of consistent hashing of server ID -> server. There are lots of ways to do this and it doesn't have to be standardized.
4. Servers continue to learn SIDs as previously. We need to add some language about nonce management -- there is some annoyance associated with incoming random CIDs "using up" nonces, but I feel confident there's a way to scale this.

This solves both issues:
A. The LB has much less state, just a lightweight, purely internal mapping that the server learns over time through the mechanism.
B. There is no high-availability issue: the backup LB just needs to have the same consistent hash

[Martin Duke]

Nonce management:

1. when learning a new SID, there will be a nonce associated with that CID (even if the nonce is too short, we can just pad it with zeros). This is the start nonce S for that SID.
2. the server keeps track of next nonce N, initialized to S + 1. When N = S, retire the SID for that config
3. If a new client-generated CID comes in with the same SID, there will be a random nonce R. There are two possibilities:
   (a) if S < R < N, this has no effect on nonce state variables. Carry on!
   (b) otherwise, this a nonce we have to take care not to reuse. Servers may do any of the following:
   (i) Set S = R
   (ii) Set N = R+1
   (iii) Add to a list of unusable nonces

[Martin Duke]

Ugh, this doesn't work. When we add a server, or if one goes down and then up again, then there's ambiguity on where to route an SID. The LB can know this and route short headers to both, but that will lead to a storm of stateless resets.

The server could use a storm of garbage packets with a given CID to mean that it should retire that SID, as it's a sign there's a double allocation. That is not elegant. Furthermore, there is no real time limit on how long the server would have to double-route, except retiring the config.