Add profiling middleware in Swift

The profile middleware provide a tool to profile Swift
code on the fly and collect statistic data for performance
analysis. An native simple Web UI is also provided to help
query and visualize the data.

Change-Id: I6a1554b2f8dc22e9c8cd20cff6743513eb9acc05
Implements: blueprint profiling-middleware
Added a tox job for running flake8 under Python 3

Change-Id: I04a78cc5e3613d1d765d716633bca297bf7207b6
Add targeted config loading to swift-init

This allows an easier and more explicit way to tell swift-init to run on
specific servers.  For example with an SAIO, this allows you to do
something like:

swift-init object-server.1 reload

to reload just the 1st object server.  A more real world example is when
you are running separate servers for replication.  In this example you
might have an object-server/public.conf and
object-server/replication.conf.  With this change you can do something
like:

swift-init object-server.replication reload

to just reload the replication server.

DocImpact
Change-Id: I5c6046b5ee28e17dadfc5fc53d1d872d9bb8fe48
Merge "Added a tox job for running flake8 under Python 3"
Merge "Add profiling middleware in Swift"
Make the new xprofile tests optional.

On Lucid at least, xprofile doesn't work. While others try to figure out the
underlying issue, this patch would just skip the tests if the profiling code
can not be imported.

Change-Id: I0fee3f729742cc727edc2adabb4ed782bea7798f
Change the default token logged length to 16

Based on comments from deployers at the Juno OpenStack summit,
limiting the default logged token length (to, by default, prevent
tokens from being fully logged) is a good idea.

Change-Id: I58980e85329d99de41f1c08f75e85973452317b1
Merge "Change the default token logged length to 16"
taking the global reqs that we can

Change-Id: Icfdeeab14e90728aa8167ad6587d51e9b10cb846
added Benchmarks/Load Generators section

Change-Id: Ie4b12b91ab07987e4f9cf2d1b7d24961d22cfd37
Merge "Add targeted config loading to swift-init"
Merge "added Benchmarks/Load Generators section"
Merge "taking the global reqs that we can"
New log_max_line_length option.

Log lines can get quite large, as we previously noticed with rsync error
log lines. We added a setting to cap those, but it really looks like we
should have just done this overall limit. We noticed the issue when we
switched to UDP syslogging and it would occasionally blow past the 16436
lo MTU! This causes Python's logging code to get an error and hilarity
ensues.

Change-Id: I44bdbe68babd58da58c14360379e8fef8a6b75f7