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
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"