Fix container quota check during cross-account COPY

Container quota is not currently checking Destination-Account header
which could cause quota to not be enforced in case of copies

Change-Id: I43adb0d7d2fc14ba6c0ca419a52a5c3f138f799a
Signed-off-by: Thiago da Silva <thiago@redhat.com>
Add Expected Failure for ssync with sys-meta

Sysmeta included with an object PUT persists with the PUT data - if an
internal operation such as POST-as-copy during partial failure, or ssync
with fast-POST (not supported), causes that data to be lost then the
associated sysmeta will also be lost.

Since object sys-meta persistence in the face of a POST when the
original .data is unavailable requires fast-POST with .meta files the
probetest that validates object sys-meta persistence of a POST when the
most up-to-date copy of the object with sys-meta is unavailable
configures an InternalClient with object_post_as_copy = false.

This non-default configuration option is not supported by ssync and
results in a loss of sys-meta very similar to the object sys-meta
failure you would see with object_post_as_copy = true when the COPY part
of the POST is unable to retrieve the most recently written object with
sys-meta.

Until we can fix the default POST behavior to make metadata updates
without stomping on newer data file timestamps we should expect object
sys-meta to be "very very best possible but not really guaranteed
effort".

Until we can fix ssync to replicate metadata updates without stomping on
newer data file timestamps we should expect this test to fail.

When ssync replication of fast-POST metadata update is fixed this test
will fail signaling that the expected failure cruft should be removed,
but other parts of ssync replication will still work and some other bugs
can be fixed while we wait.

Change-Id: Ifc5d49514de79b78f7715408e0fe0908357771d3
Merge "Add Expected Failure for ssync with sys-meta"
Raise ValueError for offset on Timestamp over limit

We can't order a Timestamp with an offset larger than 16 hex digits
correctly, so we raise a ValueError if you try to create one.

Change-Id: I8c8d4cf13785a1a8eb7416392263eae5242aa407
Clean up empty account and container partitions directories.

Because we iterate over these directories on a replication run,
and they are not (previously) cleaned up, the time to start the
replication increases incrementally for each stale directory
lying around.  Thousands of directories across dozens of disks
on a single machine can make for non-trivial startup times.

Plus it just seems like good housekeeping.
Closes-Bug: #1396152

Change-Id: Iab607b03b7f011e87b799d1f9af7ab3b4ff30019
Removing unused method: _remaining_items

Removing method _remaining_items from object controller class.

The only caller to this function was removed as part of the
work to move all DLO functionality to middleware:
https://review.openstack.org/63326

Change-Id: I7fbc208746bba8142ae51bf27cfa1979cae00301
Signed-off-by: Thiago da Silva <thiago@redhat.com>
Fix reclaim on deleted containers

The common db replicator's code path for reclaiming deleted db's beyond the
reclaim age was not covered by unittests, and a AttributeError snuck in.  In
writing the test that would cover the common code both for accounts and
containers I discovered another KeyError with the container conditional for
validating the container's fully reported status.

This fixes both those issues and adds additional tests for the cleanup empty
account container partition and suffix directories.

Change-Id: I2a1bfaefebd05b01231bf71dd908fcc49adb4c36
Merge "Clean up empty account and container partitions directories."
Merge "Fix reclaim on deleted containers"
added testing notes to the contributing doc

Change-Id: Ifb83469dabbca435bd3df2c05089dc1a113c4460
Merge "Fix container quota check during cross-account COPY"
Merge "Raise ValueError for offset on Timestamp over limit"
Merge "added testing notes to the contributing doc"