Add Storage Policy Support to ssync

This patch makes ssync policy aware and adds plumbing required
for existing test cases to pass as well as required tests to
assure policy support coverage.

Change-Id: I8de43be41a10732aca05781dbd1a7ca5da6bb6b3
Implements: blueprint storage-policies
Merge "Add Storage Policy Support to ssync" into feature/ec
Merge branch 'master' into feature/ec

Change-Id: I98d95dbbedbe798d0ac29bb77aa589847bfde9da
Store policy index in container_stat table

This used to be stored in the metadata, but it has different semantics
than metadata when it comes to replication: with metadata, newest
wins, while with policy index, oldest wins. Let's store separate
things separately.

Also, this lets us do things like reference the policy index in SQL
triggers, or have a broker method that just pulls out the policy
index without everything else.

Also also, it's faster to do it this way: you don't have to
deserialize a big blob of JSON just to pull out a single integer.

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
Store per-object policy index in container

To support the object reconciler (coming Real Soon Now™), we store
each object's storage policy index in the container's 'object'
table. This way, some other daemon (replicator or something) can
locate the misplaced ones and enqueue them for the reconciler.

We keep container_stat.misplaced_object_count so that the reconciling
daemon can short-circuit if there aren't any misplaced
objects. Checking a single integer is much faster than scanning a
multi-million-row 'object' table.

We deliberately do not add the object's policy to any container
listings since that may break poorly-written clients (and aren't they
all). It's just for internal bookkeeping.

Change-Id: Iac81fc002a3636bb3dc73c6a171b72d742b9d2d1
put SPI in output of list_objects_iter

I'm not 100% certain that this is a good idea; if it is, squash it
into the parent commit please. Or maybe leave it separate? Dunno.

Change-Id: Id495d32f1cf572ab82f44892e56126a165a0bfa2
something something cleanups