Previously, when deleting a symlink that points to an xLO, we'd clean
up the xLO's segments then delete the symlink, leaving the xLO itself
busted.

Similar trouble would come from overwriting a symlink pointing to an
xLO. Check for a Content-Location in the HEAD response and leave such
segments.

Co-Authored-By: Clay Gerrard <clay.gerrard@gmail.com>
Change-Id: I45b210cf380a68bd88187c91fa2d63a8b2bb709b

Change-Id: I3dac826c1f208569c5f40431f59a2045e5744415

Symlinks have recently added some new keys to container listings.  It's
very convenient to be able to see and reason about the extra information
in container listings.

Allowing raw json output is similar with what the client already does
for the info command, and it's forward compatible with any listing
enhancements added by future middleware development.

Change-Id: I88fb38529342ac4e4198aeccd2f10c69c7396704

Previously, if you uploaded a file as an SLO then re-uploaded it
with the same segment size and mtime, the second upload would
go delete the segments it just (re)uploaded. This was due to
us tracking old_slo_manifest_paths and new_slo_manifest_paths
in different formats; one would have a leading slash while the
other would not.

Now, normalize to the stripped-slash version so we stop deleting
segments we just uploaded.

Change-Id: Ibcbed3df4febe81cdf13855656e2daaca8d521b4

Change-Id: I18a6327b3acdd4db5ae80097080c043f7c20c353

...since modern sphinx won't install on py27.

While we're at it, clean up some warnings and treat warnings as errors.

Also, fix up how we parse test configs so we can run func tests.

Related-Change: Id3c2ed87230c5918c18e2c01d086df8157f036b1
Change-Id: I3718f69610545b0dbcb0a2ab45b400da3a45682c

1. update hacking version to latest
2. fix pep8 failed

Change-Id: Ifc3bfeff4038c93d8c8cf2c9d7814c3003e73504