Database structure and procedures for the CA server
===================================================

This is information about how sessions and their progress are
represented inside the Redis database and what daemons should do
to advance the progress of a session.

Note that all values in Redis are normally stored as strings,
so references to "int" mean that the value in the database should
be INTERPRETED as an integer, not that it is natively stored as
one.


Sessions:
---------

hash:  sessionid, "created" → int
       sessionid, "live" → "True", "False"
       sessionid, "csr" → str
       sessionid, "state" → str
       sessionid, "challenges → int
       sessionid, "cert" → str

list: session:names → str


Challenges:
-----------

hash: sessionid:n, "challtime" → int
      sessionid:n, "type" → int
      sessionid:n, "name" → str
      sessionid:n, "satisfied" → "True","False"
      sessionid:n, "failed" → "True","False"
      sessionid:n, "data" → str                   # This is problematic.


Queues:
-------

list: active-requests
list: pending-makechallenge
list: pending-testchallenge
list: pending-issue
list: pending-done


Daemons should FIRST pop sessions from a queue (and check whether the
thing that was pending has already been done?); then do the thing that
was pending; then change the session's state to the next state; then
push the session ID onto the next queue.

If the server crashes, then upon reinitalization the server can go
through everything in active-requests and push it onto the appropriate
pending-whatever queue for its state if it isn't already in that queue.

How do sessions get removed from the pending-done queue?  (The server
can tell when it's told a client about a certificate issuance, but not
whether the client has received the good news.)  Do we need to have
clients send a "thanks" message to let the server know that they've
received the cert?  This could still lead to cases where the client has
received a cert but the CA never finds out about it because the client
crashes or goes offline afterward.  However, without the acknowledgement
we could have the opposite problem (the client hasn't gotten a cert, but
the CA thinks it has).