Stop getting useless bytes on manifest Range requests.

If you make a range request for a manifest object, then the proxy can
retrieve more data than it actually needs from the object server. It
sends the right bytes to the client, and then spends a bunch of time
reading and discarding bytes it doesn't need.

Example:

   file start  	       	       	       	       	       file end
       |	range start	  range end		  |
       v	     v         	       v       	       	  v
       [--------------------------------------------------]

The proxy would send a request to the object server with "Range:
bytes=${range start}-", and so the object server responds with all the
bytes from range start to file end. This needlessly transfers all the
bytes from range end to file end, as none of those are sent to the
client.

This commit fixes the sent Range header to only request the bytes
needed.

Change-Id: Ie8d4ee2c5e67c08795ac2d39d1df7d11856621a9
Refactor DiskFile instantiation in object server.

DiskFile() takes a lot of arguments whose value is the same on every
instantiation, so I pulled that stuff out into a utility method. No
functionality change is intended.

Change-Id: I259df5602bed60d6cb48e07d6d9e58e8320ee12a
Improve swift's keystoneauth ACL support

Below three bug reports talk about one thing.
Current keystoneauth ACL supports as:

tenant_name:user_id         ok
tenant_name:user_name       no
tenant_name:*               no
tenant_id:user_id           ok
tenant_id:user_name         no
tenant_id:*                 no
*:user_id                   ok
*:user_name                 no
*:*                         no

This patch will make all of above work fine.
Applying (tenant/user)name could let user put or get their data in a
more readable way. The tenant_name:* and *:user_name is suitable for
many usage.

note: to keep compatibility here add a new keystone.identity just for
authorize() itself and leave env['keystone.identity'] to other
middlerwares.

Fixes: bug #1020709
Fixes: bug #1075362
Fixes: bug #1155389
Change-Id: I9354dedaad875117f6a9072c67e9ecf69bfca77e
Merge "Stop getting useless bytes on manifest Range requests."
Merge "Improve swift's keystoneauth ACL support"
Local write affinity for object PUT requests.

The proxy can now be configured to prefer local object servers for PUT
requests, where "local" is governed by the "write_affinity". The
"write_affinity_node_count" setting controls how many local object
servers to try before giving up and going on to remote ones.

I chose to simply re-order the object servers instead of filtering out
nonlocal ones so that, if all of the local ones are down, clients can
still get successful responses (just slower).

The goal is to trade availability for throughput. By writing to local
object servers across fast LAN links, clients get better throughput
than if the object servers were far away over slow WAN links. The
downside, of course, is that data availability (not durability) may
suffer when drives fail.

The default configuration has no write affinity in it, so the default
behavior is unchanged.

Added some words about these settings to the admin guide.

DocImpact

Change-Id: I09a0bd00524544ff627a3bccdcdc48f40720a86e
Fix swift-dispersion-report.

Fixes bug 1180680.

Change-Id: I1c0eaa6f934f73853e832a8e468e1b8369a21117
Use object name from request in bulk Errors

This will allow users to more easily match the failed objects in Errors
for bulk delete requests to the object names they provided in the request.
For extract Errors, it reports the failed path from the tar archive.

DocImpact

Change-Id: I084057810fc4fb7fdac05494cc6fec2cbf81bb9d
Add sample rsyslog.conf.

Give users a sample rsyslog.conf to manage their logs easily based on
LOCAL0 swift used. In this patch I offer some choices to output logs
via commnet lines or uncomment.

Change-Id: I2fe150a6e3d164a989c3520c0b7f032897a71f18
Merge "Fix swift-dispersion-report."
Merge "Add sample rsyslog.conf."
Merge "Refactor DiskFile instantiation in object server."
Merge "Local write affinity for object PUT requests."
updated changelog and authors update for 1.9.0 release

Change-Id: I61ffbaba01aba86d61e4f3d988b5abeee8f07813
Deleted account respond as non existing accounts

Currently clients can not distinguish between non existing accounts
(which can be created) and accounts marked for deletion, which has
not yet been reaped and therefore cannot be re-created until reaped.

Following this patch, if an account is marked as deleted but hasn't
been reaped and is still on disk, responses will include a status
header:
    'X-Account-Status' = 'Deleted'

Fixes:Bug #1188609
Change-Id: Ibd39965ae3f5d45fd78f130e0e31f5a0141a8633
version bump to 1.9.1

Change-Id: If04c88f7e686f4b4709c5b68351ebbbea97d12bd
Merge "updated changelog and authors update for 1.9.0 release"
Merge "version bump to 1.9.1"