Bug 1727345

Description of problem:
Keystone Fernet tokens have been set default provider since the Pike dev cycle [1]
As reported upstream [2] and [3] the general API responsiveness has been impacted, in some cases, by even 70% slower response.

While in some environment such degradation is generally not an issue, specifically for Telcos, the VNF life-cycle is impacted. To what extent, it depends on the VNF complexity we're dealing with. For instance, vEPC, one of the most common NFV use-case has many components. SGW and PGW are connected from dozens to even hundreds of networks. Backup and Restore when relying on the OpenStack API can get much slower, potentially affecting the SLA.

Revering the token driver to UUID is not a scalable approach. Upstream has proposed a solution: in order to revert to comparable UUID responsiveness level, a shared Memcached backend for all the services is required in order to cache as much Keystone data as possible. Upstream has/had a proposal [4] (on-hold since months) focused on the Keystone tokens while in the OpenStack community has been proposed a much wider caching scope [5] including catalog, domain_config, revoke, roles, identity, tokens even at the issue time.

The initial upstream approach is a starting point but it's not good enough. The community approach is far better.
Some people have expressed concern regarding the responsiveness in the even a Memcached server is unavailable while forgetting to remember that when RabbitMQ is unavailable, OSP is far slower and totally unusable (and not only for Telcos)

Version-Release number of selected component (if applicable):
OSP13, OSP14, OSP15, OSP16

How reproducible:
Run standard tempest against an OSP13 with Fernet and then with UUID token and compare the results.  

Actual results:
Multiple OpenStack APIs are slower than OSP10. 

Expected results:
OSP10-level API responsiveness or even better but certainly not worse.

Additional info:
[1] https://github.com/openstack/tripleo-heat-templates/commit/c737eea8c0594bce5c86cd712dab559fa5d1a385
[2] https://review.opendev.org/#/c/634505/ please see comment by "Lukas Bezdicka" on the "Feb 13 3:37 PM"
[3] https://docs.google.com/document/d/1zpi9OP_RrZv4ACy43HnqYNoTIRU6j10JJaQI9HB5ugY/
[4] https://review.opendev.org/#/c/634505/
[5] https://www.holdenthecloud.com/2018/05/10/keystone-optimization/