remove debugging print

Change-Id: I9be807f5cbb60b8ce36ff32c92ba77a3e2cd2587
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
Merge "Merge branch 'master' into feature/ec" into feature/ec
Merge "Store policy index in container_stat table" into feature/ec
Purge self.policies from Swift

Since we decided to go with a global policy set that we swap out in
tests, we don't need these dependency-injection remnants any more.

Change-Id: I43411f774c09bd1197db70c3ca8889ba49009e2d
Move patch_policies in obj server tests

By hoisting this stuff up into a decorator, it leaves the bodies of
the test methods less cluttered and easier to read.

Change-Id: Ifa049bd13d2ef48d07d98ddc2ad2fe8b6513b5d4
tiny stylistic fixup

Change-Id: I2b14bffbef7992852cbff9864a3369a23aebc4c8
Merge "Fix changing of storage policy index" into feature/ec
Merge "Purge self.policies from Swift" into feature/ec
Merge "tiny stylistic fixup" into feature/ec
Merge "Move patch_policies in obj server tests" into feature/ec
Merge branch 'master' into feature/ec

Conflicts:
	swift/container/server.py
	swift/obj/auditor.py
	swift/proxy/controllers/container.py
	test/unit/obj/test_auditor.py
	test/unit/proxy/test_server.py

Change-Id: I9e52c6c9183d93cb17db8881de0ad23ac7ef97e1
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
Add container reconciliation to container updater

Under normal circumstances, an object lives in storage policy N, where
N is the value from its container's container_stat table. However,
under some circumstances involving network failures and such, it can
happen that an object is actually stored in a different policy than
its container.

This commit introduces functionality in the container updater to move
misplaced objects to their proper places. I chose the container
updater because it's already doing a filesystem walk and inspecting
every container DB, so when nothing is misplaced, no extra work is
being done. I used a separate greenpool for the work so that account
stats would still be updated with the same latency as before.

NOT DONE YET, like, the daemon isn't written. The cleanup stuff is written though

Change-Id: I2d90503d8378f7ac85344c9abaf0b3c925c63709
Handle storage policies in container replicator

The container replicator will now sync up storage policy between two
different container DBs. The policy from the older container is kept,
or if the containers are the same age, a tiebreaker of lesser-policy
is used (this seems unlikely to occur, but we need some kind of
tiebreaker just in case).

The reason for keeping the older container's policy is that policy
mismatches are most likely to occur when a container is unavailable
for a short span and the application recreates it. When this happens,
the older container DB is likely to contain far more objects than the
newer one, so by picking the older, we minimize the number of
misplaced objects.

Change-Id: I0878fb32f30effd24eb791f6bed62a6045a2e8e5
wip reconcilerator

Change-Id: I22bf42b83fa1f824ab2b1cc649c3a7f6f246e190
wip omg wtf is this

Change-Id: I36d811268c7f11cd6ca63cefa5c92e62965b385d