Session token management improvement

Summary:
Refactor the token management in session

Motivation:

The Token object is used by django_openstack_auth to encapsulate user and keystone related information. This is used to rebuild the django User object.

It currently stores:
1. keystone token
2. user info
3. scope
4. roles
5. service catalog.

It is currently stored in the django session to retrieved on subsequent page reload.

When a signed cookie session backend is used, the application may hit the 4k cookie limit size. One
of the reason for the growth of the cookie size is the service catalog. As more services are registered
the bigger the size of the service catalog would be.

Using default devstack setup, the service catalog take 31% of session size for V2, and 44% for V3.

The token should store the minimum information and stop storing the service catalog to be able to scale and not hit the cookie limit.

Description:

There are a number of items to be implemented
1. Token object should store the minimum data:
- keystone token
- scope
2. The rest of the information will be stored in django cache instead of storing in the session
https://docs.djangoproject.com/en/1.8/topics/cache/
3. An entry in the django cache will be created for each scoped token:
- key: token_id
- value: access_info from keystone
- expiration: token expiration
4. When horizon rebuild the user object, it will first fetch the Token object from the session.And then fetch the rest of the information from the django cache, using the token as the key.
5. If no entry from the cache can be found, it will request the access_info from keystone and store that in the cache

UX:
N/A

Outside Dependencies:
N/A

Requirements Update Required:
N/A Cache is available since Django14

Doc Impact:
Will have to document that deployer have to configure the Django Cache correctly.