Fix fd leak from get_logger() in python 2.6

Calling get_logger({}) instantiates a logging.handlers.SyslogHandler,
which opens and keeps a socket around (either /dev/log or UDP or
whatever; not important).

Under Python 2.6, all logging handlers instantiated anywhere at all
will live for the entire lifetime of the program; they get stored in
logging._handlerList and logging._handlers. Python 2.7 is very
similar, but uses weakrefs instead of strong references in those
module-level variables, so logging handlers can actually get cleaned
up prior to program exit.

The net effect is that any program that calls get_logger() more than a
fixed number of times will leak file descriptors under Python 2.6.

This commit throws encapsulation out the window and, under 2.6 only,
replaces strong references with weakrefs in logging._handlerList and
logging._handlers, thus avoiding the leak.

Change-Id: I5dc0d1619c5a4500f892b898afd9e3668ec0ee7c
Remove blank space after print

Check Swift code, remove blank space after print.

Change-Id: Ia7838ac5f33f2b335d1cd664b017e87118262d29
Merge "Fix fd leak from get_logger() in python 2.6"
Make DLO manifest copying work with ?multipart-manifest=get

If a client issues a COPY request for a DLO with the query param
multipart-manifest=get, then the expectation is a new
manifest. However, this wasn't the case; X-Object-Manifest wasn't
being set on the new object, so the result was a normal object with
the same contents as the old manifest (typically 0 bytes).

There was already a mechanism by which middlewares could modify COPY
requests; this commit extends that so they can set headers on the new
object.

Note that this has nothing to do with a "normal" DLO copy, i.e. one
without multipart-manifest=get. That one makes a new object that's the
concatenation of the segments, and it was working just fine.

Change-Id: I1073af9fee6e34ebdfad7b1a89aeb05e4523a151
Merge "Remove blank space after print"
Object server PUTs should respect client_timeout

It seems the object server never respected the client_timeout value
since the beginning of Swift. This is normally fine since the proxy does
and will normally hang up on the backends. But if the proxy has a bug or
if there's network issues or whatever, the object server should be smart
enough to enforce this timeout as well.

Our operations guys noticed this problem when older processes would
never exit after a reload. They started investigating and saw that the
object server had open tmp files that hadn't been touched in quite some
time. Sometimes the tmp files didn't even exist anymore since the
reclaimer deletes really old untouched tmp files.

Change-Id: Iba0397203a2dccca4a28a8c8cbfc5a60e429837a
Merge "Make DLO manifest copying work with ?multipart-manifest=get"
Use new style class for ringbuilder's Commands

classs Commands:

==>

class Commands(object):

Change-Id: I160a10f4380b41dc76d5b359aa66c42b3242e940
Merge "Object server PUTs should respect client_timeout"