Fix object auditor recon and logging

1. Nothing is logged until at least one audit needs more than log_time.
   If the audit runtime never exceeds this value (which is 3600 seconds
   by default) nothing is logged and the recon entry is never updated.
   It happens especially on very fast disks with a low usage and/or if
   only a few disks are audited (for example, using the --devices
   parameter on the command line).

   This patch changes this to log and update the recon cache entry
   at least one time after the first device audit.

2. If device_dirs is set the recon entry will be deleted after all
    devices are audited.

Change-Id: Ifa504d21389b3a5f7eaf914b19d6e26543dac121
Update tempurl docstring with methods config option

Adds a description of the methods config option to the
docstring.

Also fixes description of swift.source value and a
couple of other typos.

Change-Id: If3489087df020536ff663ffe4e249c300ea2d506
Sleep for longer at a time in lock_path.

When lock_path is called and the lock goes for the whole 10 seconds,
the flock is called 1000 times. With this patch, the short 0.01 sleep
is used for the first 1% of the total lock time and then 1% of the
total lock time is used.

Change-Id: Ibed6bdb49bddcdb868742c41f86d2482a7edfd29
Shard expiring object container

All the expiring objects for a given X-Delete-At are funnelled into the
same expiring object container- this can act as a bottleneck.

Change-Id: I288a177a7ae3e213c727a2a81fa76d4ef9cf7eb3
Merge "Sleep for longer at a time in lock_path."
Merge "Fix object auditor recon and logging"
add the account management config values to swift info

added account_autocreate and allow_account_management to
the /info endpoint

Change-Id: I4b239c9cefb728c3c93bf75cad065c72edf2fc0a
Merge "Update tempurl docstring with methods config option"
Merge "Shard expiring object container"
Delete expired objects in smarter way.

When the expirer tries to delete customer objects, if it just walks through the
containers in order the deamon will tend to send DELETEs to the same container
highly concurrently. This will in turn create a lot of asyncs because of all
the concurrent deletes. If the deletes were spread out to multiple containers
it would improve performance and decrease the number of asyncs made.

Change-Id: I3d08118c197b7f18dd7e880bd5664508934ffd24