Change-Id: I2cc3ba8d0064d6f424f16be94deaecdf1c5c8332

Custom SSL handling was introduced because disabling SSL layer compression
provided an approximately five fold performance increase in some
cases. Without SSL layer compression disabled the image transfer would be
CPU bound -- with the CPU performing the DEFLATE algorithm.  This would
typically limit image transfers to < 20 MB/s. When --no-ssl-compression
was specified the client would not negotiate any compression algorithm
during the SSL handshake with the server which would remove the CPU
bottleneck and transfers could approach wire speed.

In order to support '--no-ssl-compression' two totally separate code
paths exist depending on whether this is True or False.  When SSL
compression is disabled, rather than using the standard 'requests'
library, we enter some custom code based on pyopenssl and httplib in
order to disable compression.

This patch/spec proposes removing the custom code because:

* It is a burden to maintain

 Eg adding new code such as keystone session support is more complicated

* It can introduce additional failure modes

 We have seen some bugs related to the 'custom' certificate checking

* Newer Operating Systems disable SSL for us.

 Eg. While Debian 7 defaulted to compression 'on', Debian 8 has compression
 'off'. This makes both servers and client less likely to have compression
 enabled.

* Newer combinations of 'requests' and 'python' do this for us

 Requests disables compression when backed by a version of python which
 supports it (>= 2.7.9). This makes clients more likely to disable
 compression out-of-the-box.

* It is (in principle) possible to do this on older versions too

 If pyopenssl, ndg-httpsclient and pyasn1 are installed on older
 operating system/python combinations, the requests library should
 disable SSL compression on the client side.

* Systems that have SSL compression enabled may be vulnerable to the CRIME
(https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4929) attack.
Installations which are security conscious should be running the Glance
server with SSL disabled.

Full Spec: https://review.openstack.org/#/c/187674
Blueprint: remove-custom-client-ssl-handling

Change-Id: I7e7761fc91b0d6da03939374eeedd809534f6edf

In v2, it's only show Id and Name. When use --verbose, although added
owner and status, it's still lack of Disk-format,Container-format and
Size.

Change-Id: I26b4b7bd3a3f6dbf82ca73c32dd94c56e8e173a1
Closes-bug:#1486329

Currently glanceclient doesn't enforce disk-format or container-format
presence in the command line on image-create when providing image data
(with --file, --location, --copy-from), which means that the POST
request is made with the whole image and error is reported by Glance
API.

This post enforces presence of those arguments when image data is
provided so we can get the error quicker and avoid sending unnecessary
data over the network.

Change-Id: I5914fa9cfef190a028b374005adbf3a804b1b677
Closes-Bug: #1309272

Now that we have stable branches for clients, it's easier to keep track
of the current default image's schema in Glance and update it
respectively. This patch adds the current image schema, including the
schema-properties.

One good reason to do this is to be able to react when a running Glance
instance is not around to be introspected. It's really unfortunate that
things like help text can't be rendered when there image schema is not
available in the system.

We could keep the schema in a json file but rather than shipping data
files with glanceclient we can just have it in the python modules.

Change-Id: I9b8cc1d18d6717ccf991fb8149ab13c06d653ee4
Closes-bug: #1481729