Store policy index in container_stat table

The eventual goal is to have policy index stored per-object in the
objects table and have a count of mismatched objects in the
container_stat table which is magically kept up-to-date by a
trigger. As part of that, I need the trigger to know the container's
policy index, so I moved it to a convenient place.

I considered making an extract_spi sqlite function similiar to chexor
and calling that from the trigger, which would go something like this:

 * read a multi-kilobyte blob of text out of container_stat
 * pass it from sqlite to python
 * run it through a JSON decoder
 * pull out one single value
 * return that from python back into sqlite

Of course, once I saw the data flow there I ran away screaming and put
policy index in container_stat instead.

Change-Id: I26f7ef09201970ee876ac24f39d0b2d4895bfda9
Fix changing of storage policy index

The commit that the storage policy moved out of metadata and into
container_stat introduced a bug: if the client DELETEs and then PUTs a
container with a different storage policy, the resurrected container
still had the old policy. This is because the policy was being set in
broker.initialize(), but that was only being called for new
containers (no .db files at all).

Now the policy index is still set at initialization for new
containers, but it is updated for resurrected containers.

I considered using broker.set_storage_policy_index() for all
containers, new or resurrected, but that would leave a brief window of
time for new containers where the .db file has the default policy
index and not the user-specified one, and that seemed like a good home
for bugs to move into.

Change-Id: I496e5078df80ec1466c1d50ac62ae3700c5aeec0
Put X-Timestamp in object 404 responses

This way the container reconciler can tell (sometimes) that an object
was deleted at a certain time.

Change-Id: I3a56f2367585803b82f0b254946896c34746f9ca
Add object-reconciler daemon

This daemon will take objects that are in the wrong storage policy and
move them to the right ones. It operates on a queue similar to the
object-expirer's queue.

Discovering that the object is in the wrong policy will be done in
subsequent commits by the container replicator and the object updater;
this is the daemon that handles them once they happen.

Like the object expirer, you only need to run one of these per cluster.

Change-Id: I787f2a5ec2be7804eed87329cf6718f14027baea
Make the container replicator notice misplaced objects

If replication is attempted between two container DBs that have
different storage policy indices, then the older DB wins. When this
happens, all the objects in the newer DB are enqueued for
reconciliation.

This only happens on the sender (replicator) side of container
replication; on the receiver (container server) side, a 409 response
is returned. We can't go enqueue things on the receiver side because
it might take a really long time, and that's a bad idea to do in the
middle of servicing an HTTP request.
Make object updater reconcile on 409s

When the object updater gets a full set of 409s from the container
servers while processing an async-pending, that means the object in
question is in the wrong storage policy. Thus, the object updater will
enqueue it for reconciling.

Change-Id: I0f81ec4c22bdfd2d2c785e4c807cdf5368a75b24