Update tox.ini so flake8 works even without hacking

The flake8 command (when run from the command line or via vim-flake8) seems to
bypass the the normal pep8 [W]arning and [E]rror as well as py[F]lake checks
if the project level tox.ini includes a select, but doesn't include them in
it's select option (tested on flake8 v2.0 and v2.1).  Somehow if hacking is
installed these checks always run even if they're not explicitly listed in the
select list - but adding them so flake8 works on our project even without
hacking doesn't seem to cause any problems.

Also The [flake8] section's "select" option in tox.ini doesn't seem to run all
checks when presented with the space-comma seperated list.  I had to pull out
the bare except check (H201), because our hacking fix for the "H201 # noqa"
hasn't been released to pypi yet (maybe hacking version 0.9.0?).

As far as I know the Swift core development team is fully onboard with pep8,
and the flake8 checks are mostly like "unused import" stuff - so I *think*
this change is more about making the tool test what we want it too and not
changing or adding any new requirements or expectations.

Change-Id: Ia911c63745100cce182d5c5eb67b77e31c1e9b18
Added swift-container-info tool.

This is a very simple swift tool to retrieve information
of a container that is located on the storage node.
One can call the tool with a given container db file
as it is stored on the storage node system.
It will then return several information about that container.

Change-Id: Ifebaed6c51a9ed5fbc0e7572bb43ef05d7dd254b
Removed hard coded location of ring

In bin/swift-object-info, removed the hard coded location of ring.

Change-Id: Ie328633f5f4de755c9dcc4bb52341bb97087419d
fix a skipped account ACLs functional test

closes bug #1292158

Change-Id: Ic74c9d698c312b484a49d759eced6860d46cf399
Bump up sleep when expecting a timeout

It seemed like some of the tests ment to exercise the proxy's timeout could
would occastionally race and the backend mock would be able to cough up a
chunk before the timeout fired in the proxy - typically resulting in a failed
assertion like " lalala" != 'lalala'.

We paramaterize the timeout value, and bump it up for those cases where we are
expecting to hit the timeout.  Timing shows this change is just as fast for
passing tests.  And if you want to break the node_timeout in
proxy.controller.base you can verify the tests are still just as effective -
if a bit slower to detect the failure path.

Fixes bug #1272509

Change-Id: Iaf91d9d551e94fc317a08e8c0ee02daeed331b60
Update swift3 repository

The swift3 project was moved to StackForge.

Change-Id: I3a7108d57b3b9ed3d8594545ff4d67dcab86ca07
Merge "Added swift-container-info tool."
Merge "fix a skipped account ACLs functional test"
Merge "Update swift3 repository"
don't repatch mimetools again. and again. again.

Change-Id: Id8ccb269ede6981dba8a5e119316e3447074193c
Merge "Bump up sleep when expecting a timeout"
Merge "Update tox.ini so flake8 works even without hacking"
Merge "Removed hard coded location of ring"
Invert which proxy logging middleware instance logs

Prior to this patch the proxy_logging middleware always prepared to
read the response and process it for access logging, where the
proxy_logging instance first to handle the response bytes marked the
request as "logged".

This meant that the proxy_logging instance immediately before the
proxy-server app (right most in the pipeline, if properly setup) would
always log the responses for all the client requests, regardless if
middleware to the left of it still had processing to do for the
response. This would break SLO, where the slo middleware passed along
the GET of the manifest, unchanged from the client, so that the right
most proxy logging middleware would log the sponse for just the
manifest, but then the slo middleware would fetch all the segments of
the manifest, feeding them out in the response to the client, the
request now marked as "logged" so that the left most proxy logging
middleware would not log it.

This patch inverts this behavior so that now the first proxy_logging
middleware instance to receive a request in the pipeline marks that
request as handling it. So now, the left most proxy_logging middleware
handles logging for all client reaquests, and the right most
proxy_logging middleware handles all other requests initiated from
within the pipeline to its left.

Closes bug: 1297438

Change-Id: Ia3561523db76c693e4e0b2c38f461544dfcee086
Write out ring.gz's in a safer fashion

Write the ring file to a temporary location first and then move it into
place. This should help prevent issues like reading a partial ring file
while a new instances is being written out.

Change-Id: I28357a2f038a51cb9d823822b92f736dff033a9e
Merge "Write out ring.gz's in a safer fashion"