Now v2 API uses code from v3. It's confusing and logically incorrect.
This patch makes v3 API as an extended version of v2.

The next patches related to this bug duplicated code between v1 and v2,
v2 and v3 will be removed.

Change-Id: I90a2b713556e91db69270a03ef6b798e08f93f90
Partial-Bug: #1643584

Add support for Cinder API /v3 endpoint.
A couple of unit tests for /v3 endpoint were added to v3/test_shell.py
to ensure that the v3 shell works, and to also test that modules work
with:
from cinderclient.v2.availability_zones import *
syntax.

Change-Id: I6ae0ada221bebb4ab1850d9c99b10fcbb585201f
Implements: https://blueprints.launchpad.net/python-cinderclient/+spec/add-v3-endpoint-support

Cheesecake introduces a host based replication use case.
This change includes the changes needed to support those
implementations in the Cinder API.

Implements: blueprint replication-update

Change-Id: I74dc1a00fb4a2c05510c6159253036ac19706959

Added request_ids attribute to resource object for all the
cgsnapshots, consistencygroups, qos_specs, quota_classes,
quotas and services APIs by updating following APIs:

cgsnapshots: delete, update
consistencygroups: delete, update, create
qos_specs: delete, associate, disassociate, disassociate_all
quota_classes: update
quotas: update
services: enable, disable, disable_log_reason

These changes are required to return 'request_id' from client to
log request_id mappings of cross projects.

For more details on how request_id will be returned to the caller,
please refer to the approved blueprint [1] discussed with the
cross-project team.
[1] http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html

DocImpact
'request-ids' will be returned as an attribute with response object.
User can access it using 'res.request_ids' where 'res' is a
response object.

Change-Id: I7b399512fcec9ecd31938656deb60e325bb76ad4
Partial-Implements: blueprint return-request-id-to-caller

Adds cli option to allow users to give reason
for service-disable. Also adds disabled reason
as a column in service list, so any disabled service
can be seen with reason.

A recent cinder change that allows disable-log-reason
allows users to provide reason for disabling service.
This just adds the cli option for the method.

Implements bp record-reason-for-disabling-service

Change-Id: I90f4566764790eeb0c047c4a0fd0108050ab6ad9

It should be "Disable" but not "Enable" in doc string when disable
a service.

Change-Id: I658090d4e218222c76947c37f340fb2ab7d26ce3

When disable/enable a cinder service, there is no output, this
caused end user does not know if the service was disabled/enabled
successfully.

It is better add some output for the command just like nova to tell
end user the service status.

Change-Id: I9d440ab7437c268b17627e255f152db0b3bf4f53
Closes-Bug: #1261120

NOTE:
* openstack/common/* should be synced from oslo, so i leave them
untouched.
* add (c) symbol for related lines, leave others untouched.

Change-Id: I46a87c7f248d3468b1fdf5661411962faf2fb875
Fixes-Bug: #1214176

Implement client bindings for Cinder os-services API extension, so
client would be able to list services, enable or disable particular
services.

Usage:
cinder service-list [--host <hostname>] [--binary <binary>]
cinder service-enable <hostname> <binary>
cinder service-disable <hostname> <binary>

This change is depended on following change at Cinder side
I7f3fa889294ca6caebdf46b8689345bcac1cdf54

Implements blueprint os-services-extension

Change-Id: I4a53fd545ed3b446441302d00a429168a996a34a