Synced jsonutils from oslo-incubator

The sync includes change that drastically enhances performance on Python
2.6 with fresh simplejson library installed.

The latest commit in oslo-incubator:
- 732bdb6297eb9de81667f7713ebcb1ccc2ee45a7

Change-Id: Ib3dc0b713ed90396919feba018772243b3b9c90f
Closes-Bug: 1314129
Make auth_token return a V2 Catalog

As there is no way to distinguish a v2 or v3 catalog from the headers
provided to an application we will for the meantime always return a v2
catalog. This should not cause any issues as the full token data is not
provided to the service so there is no-one that will get caught out by a
v2/v3 mix, and anyone that is already supporting the v3 catalog format
will have to support the v2 catalog format as well so it will continue
to work.

Change-Id: Ic9b38e0ba4682b47ae295bd3f89bac59ef7437cf
Closes-Bug: #1302970
Move auth_token cache pool tests out of NoMemcache

There were cache pool tests in NoMemcacheAuthToken. Since this class
un-imports memcache, setting the memcached_servers option would just
be ignored anyways.

The tests were moved into a separate class and changed to not set
memcached_servers. The behavior should be the same.

Also, there was a cache pool test in CommonAuthTokenMiddlewareTest
that fit better in this new class.

Change-Id: Icfce7398f2a29753200c2010bba58924980622c0
Cached tokens aren't expired

The auth_token test said that the cached tokens are expired. The
tokens weren't expired, so remove the code.

Change-Id: I8ce30cc09ee9bbc19cc4ebdb5d935a80d2d5d473
Move auth_token tests not requiring v2/v3 to new class

The tests in CommonAuthTokenMiddlewareTest run for both v2 and v3
tokens, but contained tests that weren't affected by the token
version.

The tests that aren't affected by the token version are now in
their own class.

Change-Id: I0e8aecafcd8e0da262dded48a612c84b1629d953
Remove importutils from oslo config

The importutils module is only used by other oslo modules, so
remove it from openstack-common.conf. It'll be pulled in
automatically if it's needed.

Change-Id: Iaa7e047a9ff76f911f8c64b45ceb1f240855670a
Discovery URL querying functions

The existing discovery mechanism is geared around allowing users to
create appropriate client objects. It does not provide any means to
query version responses to determine the URLs of available versions.
This patch adds url_for (similar to the functions available on service
catalog) and data_for functions that can do lower level queries for
URLs and version response data.

Because of the client creation functionality the existing discover.py
cannot be imported from within keystoneclient due to cyclical dependency
resolution. The querying functions are therefore added to a private
keystoneclient file and exposed to the original Discover object via
inheritance. This private object can then be used within the
keystoneclient library.

Blueprint: endpoint-version-query
Change-Id: I7e1891536289c57ad3fbe8ef1c6e50b7344d83d5
Sync with oslo-incubator 2640847

Sync with oslo-incubator commit
2640847e3df7720457103d2111846c27fc8fdcd5 .

First, remove the existing code to cleanup:

 $ rm -r keyestoneclient/openstack/*

Then, sync from oslo-incubator:

 $ python update.py ../python-keystoneclient

Change-Id: Ic94906002e0257ffc56245e49890e7ee2f3b4a2a
Merge "Synced jsonutils from oslo-incubator"
Merge "Discovery URL querying functions"
Regions Management

Client code for v3 API regions implementation.

Change-Id: I5c1526457395ba3fb06977bea775ff572ec840ba
Closes-Bug: 1289519
Add mailmap entry

Add mailmap entry for my email address

Change-Id: Ia46c28c86ef3f440556b1b027d2bf0a7f3e721c5
OAuth request/access token and consumer support for oauth client API

Add support for creating request and access tokens,
and to authorize request tokens. Also adding basic CRUD for
consumer entities.

DocImpact
Change-Id: Ib9d0b223f202a7e33cbad1602da5be7479cd3284
implements: bp add-oauth-support
Merge "OAuth request/access token and consumer support for oauth client API"
Merge "Regions Management"
Compressed Signature and Validation

Allows for a new form of document signature.

pkiz_sign will take data and encode it in a string that starts with
the substring  "PKIZ_".  This prefix indicates that the data has been:
1) Signed via PKI in Crypto Message Syntax (CMS) in binary (DER) format
2) Compressed using zlib (comparable to gzip)
3) urlsafe-base64 decoded

This process is reversed to validate the data.

middleware/auth_token.py will be capable of validating Keystone
tokens that are marshalled in the new format.  The current existing
"PKI" tokens will continue to be identified with "MII", issued by
default, and validated as well.  It will require corresponding changes
on the Keystone server to issue the new token format.

A separate script for generating the sample
data used in the unit tests,
examples/pki/gen_cmsz.py,
also serves as an example of how to
call the API from Python code.

Some of the sample data for the old tests had to be regenerated. A
stray comma in one of the JSON files made for non-parsing JSON.

Blueprint: compress-tokens
Closes-Bug: #1255321

Change-Id: Ia9a66ba3742da0bcd58c4c096b28cc8a66ad6569
add docstr to v2 shell module regarding CLI deprecation

Change-Id: Iaafd00671c634ab64352c5cfab0470dae0b53c35
auth_token hashes PKI token once

auth_token was hashing the PKI token multiple times. With this
change, the token is hashed once.

Change-Id: I70d3339d09deb2d3528f141d37138971038f4075
Related-Bug: #1174499
Mark keystoneclient as being a universal wheel

Change-Id: I216b422175dba6e1ca1623c21ff87f4d2fd0a486
Fixes an erroneous type check in a test

The latest version of requests changes the type of a Response's history.
See https://github.com/kennethreitz/requests/commit/b8128d6

Closes-Bug: #1321042
Change-Id: Iba9fa20d22d878a4298a35e270338ee442031796