In the cross project workshop "Establishing key themes for the Mitaka
cycle" [1] during the Mitaka summit, one of the agreed point was to
implement functional tests for the client libraries. [2]

Later on, this will serve to improve our backward compatibility for
client libraries. See I72e4e9cfa0539f6b326a0296c065fa3cb754f8ae

In preparation to implement the functional tests for both v2 and v3
clients, this patch initializes the new directories and adds the base
test classes: V3ClientTestCase and V2ClientTestCase.

Each class instantiates its specific keystoneclient version via
os-client-config either based on a clouds.yaml config file or from the
environment variables.

[1] https://mitakadesignsummit.sched.org/event/edd78ade4c7c92581a7cabc26019a85a
[2] https://etherpad.openstack.org/p/mitaka-crossproject-themes

Change-Id: Ia73d72d5f87051fb46d733782275b548874a1def

Wrap a list of objects into custom class with additional attributes.

This is wanted by Horizon, that wants to know that the list returned
from keystone is not full and that more strict filters need to be
applied.

Change-Id: Icfabfd055aed1648dc4130b03ec3dbf9bad4e45a
Closes-Bug: 1520244

All of the other Openstack services have a 'public' default endpoint
type. Keystone has 'admin' default endpoint type. Why not make
Keystone compliant and change the default for Keystone v3 from 'admin'
to 'public'. Keystone v2 will remain the same with an 'admin' default.

Closes-Bug: #1457702
Change-Id: I515438477dba72c2a0c4595603000690511b5700

The managers have a bad habit of reaching back into the client and
making assumptions about the values that are saved there. These
assumptions are not always correct when we use the session object.

Test all the versioned managers against a client that was constructed
with the old method and with a keystoneclient session object and a
keystoneauth1 session object.

Change-Id: I93a26db7ae7e4d887aa815108be71c72b4a1f2bb

Client tests are broadly seperated into v2 and v3. These folders don't
distinguish between the tests that are on v2/v3 auth and those that are
CRUD related. This means that the base v2 and v3 test class always
create a client object for the tests to use, even if they don't need it.

Whilst this isn't a big deal now, we want to be able to seperate only
those tests that require a client so we can test them with multiple
different styles of client.

Add a new ClientTestCase class that will construct a client object for
the tests that need it.

Change-Id: I61f463ac5e878107c1889672f4d4cf5874821363

The __eq__ of apiclient.base.Resource will return True,
if the two objects have same id, even if they have different
other attributes value. The behavior is weird and don't
match the semantics of object equal. The objects that have
different value should be different objects.
Fix this issue and add some test cases in this patch.

Change-Id: I1565c6e66d6dd6cf7bd2b7e8526157190deb45de
Closes-Bug: #1499369