Caching layer implementation around driver calls.

There should be a configurable caching layer that lives above the various driver calls within Keystone. This should be configurable (using something akin to dogpile.cache) to allow for varying caching backends (in-memory, file-based, redis, memcache, etc) to alleviate load on the backend storage/mechanism for the differing aspects of keystone.

This system will encompass the feature(s) of https://blueprints.launchpad.net/keystone/+spec/cache-token-revocations and extend to also cover Identity, Token Issuance, Trusts, etc.

In absence of explicit configuration of a caching back-end, the behavior will remain the same as current with no-cache.

Key things to keep in mind are: cache invalidation, ensuring the configuration for keystone is extended to expose a reasonable featureset of the caching layer.

It will be on the developer to ensure that the decorator is added to new methods (as needed) and invalidation will be handled in a consistent manner. The cache interface within keystone will provide a way to be consistent with the implementation of the cache across the different drivers and subsystems within keystone.

The initial discussions via IRC was to provide access to a series of decorators that will decorate the various driver calls, allowing for caching-in-line (via dogpile.cache/memoization) based upon the arguments to the various methods/functions.

An example implementation is outlined: https://review.openstack.org/#/c/38866/

In conjunction with this, caching layer, normalization of the use of kwargs when calling manager methods needs to be completed. The main issue with kwargs, is that the dogpile.cache only supports the use of args (not kwargs) with the default key-generator. If we provide a new generator that can support kwargs, there is a lot more work to ensure that the invalidate() calls (when required) will produce expected results since the arguments will need to generate the same key in the cache. The extra level of introspection of the actual function needed to ensure consistency with kwargs support seems like it could have adverse side-effects, performance-impact, and possibly make the code much harder to maintain/follow.

The kwargs change has the added benefit of making the drivers/managers where kwargs are used more consistent with the rest of keystone (In some cases, notably token drivers/providers, there are extensive uses of kwargs to methods).