This patch removes a debugging print statement that slipped into
service.py in patch https://review.openstack.org/#/c/85453/

Change-Id: I80eee49eaa74b52e9c36f00669206aa7b2cdec9b

Fixes a regression that is preventing swiftclient from
authenticating using keystone v3 options.

swiftclient/shell.py processes the dict of command
line options to set up a child dict ('os_options')
of keystone auth specific options (line 960). The
processing includes stripping --os- prefixes from
the command line options before adding keys to
os_options.

A recent patch https://review.openstack.org/#/c/85453/
introduced a duplication of this option processing
in service.py (line 79) which replaces the os_options
created in shell.py, but omits keystone v3 related
options. Consequently the keystone v3 options are
not being passed to the client get_auth() method.

This patch adds the keystone v3 related options to
the option processing in service.py.

For pragmatic reasons (i.e. fixing the bug quickly)
the option processing code has not been removed from
parse_args in shell.py. It is likely that the code in
parse_args is now redundant, but all code paths between
parse_args and process_options should be inspected and
test coverage added before removing that code.

Unit tests have been added in test_shell.py to verify
that command line options are correctly passed to the
client get_auth method.

The MockHttpTest class is re-used in test_shell.py,
so it is moved from test_swiftclient.py
to tests/unit/utils.py

Closes-bug: #1372465

Change-Id: I4fed013cdb8936509609d06093337cc147ade0d6

When the account response includes 'X-Storage-Policy-X-Container-Count' the
command helpers will stick a helpful extra line in the output.

If the swift response doesn't include the information the behavior is
unchanged.

Change-Id: Iaaa55d207ebe6a9c16e52adb56eb858c57cfb26a

Cannot help streamlining the code a bit, sorry. But the meat is that
we should not try to make directories if output path is explicit.

Previously we created directories using the URL path, which is
obviously wrong if explicit output file is supplied... unless
a crafty user supplied the same path with -o that is contained
in the URL path. If anyone was doing such tricks, it's not going
to work anymore (we are forcing a regression for the sake of
theoretical correctness here).

Fixes bug: 1369546

Change-Id: Ifce31f2ba233eb55550f3810348bf16bf2447d62

This patch adds a SwiftService class that incorporates the high
level logic from swiftclient/shell.py. It also ports shell.py to
use the new class, and updates the code in swiftclient/multithreading.py
to allow the SwiftService to be used for multiple operations whilst
using only one thread pool.

Currently, code that imports swiftclient has to have its own logic for
things like creating large objects, parallel uploads, and parallel
downloads. This patch adds a SwiftService class that makes that
functionality available in Python code as well as through the shell.

Change-Id: I08c5796b4c01001d79fd571651c3017c16462ffd
Implements: blueprint bin-swift-logic-as-importable-library

If a user creates an object with name ending with a slash, then
downloading such container ends in a traceback like this:

..............
test5g.file [auth 1.516s, headers 1.560s, total 244.565s, 22.089 MB/s]
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/swiftclient/multithreading.py", lin
    result = self.func(item, *self.args, **self.kwargs)
  File "/usr/lib/python2.6/site-packages/swiftclient/shell.py", line 403, in
    fp = open(path, 'wb')
IOError: [Errno 21] Is a directory: 'first-pseudo-folder/'

The proposed fix is not to save this object. Note that the contents of
the object are available with --output option, as before. Only the
crash is fixed.

Even though we do not use the contents, we download the object and
check its Etag, in case. We also create a corresponding directory,
in case the pseudo-directory contains no objects.

The format of printout is changed, so user realizes easier when
pseudo-directory convention is in effect. Note that this is not a
compatibility issue because previously there was crash in such case.

Change-Id: I3352f7a4eaf9970961af0cc84c4706fc1eab281d