Making token validation api returns service catalog

[zhiyanliu]

Currently access info token validation api returned doesn't include service catalog dict, it causes some projects couldn't work well as it designed: upperlayer project uses those endpoints to call other servies for the necessary handling of function, e.g. Heat, as an example the follow execution stack could be triggered by a standard stack creation usecase. And, as code logic shown, keystoneclient has such related parsing and construction logic as well.

https://github.com/openstack/heat/blob/master/heat/engine/properties.py#L296 https://github.com/openstack/heat/blob/master/heat/engine/constraints.py#L576 https://github.com/openstack/heat/blob/master/heat/engine/clients/os/glance.py#L35 https://github.com/openstack/heat/blob/master/heat/engine/clients/client_plugin.py#L50 https://github.com/openstack/heat/blob/master/heat/common/heat_keystoneclient.py#L196 https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/httpclient.py#L174 https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/access.py#L532 https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/service_catalog.py#L271

Signed-off-by: Zhi Yan Liu zhiyanl@cn.ibm.com

[jimlindeman]

+1 The refactor to reuse the catalog reporting logic looks good.