Refactor pluggable enforcement models

[Lance Bragstad]

The oslo.limit library exposes an Enforcer object for services to consume unified limits out of keystone. This Enforcer is responsible for understanding which enforcement model to use (configured in keystone and exposed via keystone API) and applying the enforcement properties of the library internally so that services don't have to.

The current implementation loads enforcement models as separate objects from the Enforcer. The model logic isn't built into the Enforcer object directly because we want it to be easy to add new models without changing the Enforcer. Conversely, the enforcement model objects need a lot of the same information that the Enforcer already has. This leads to sometimes awkward situations where we're passing the same data across two different objects.

We should investigate ways to improve this relationship and boundaries between enforcement model objects and the Enforcer object. The main goal is to make it easy to add new enforcement models without requiring changes to the Enforcer, but reduce the amount of duplicate information passed around internally.

This was discussed during a group code review of the oslo.limit implementation [0].

[0] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2019-07-02.log.html#t2019-07-02T16:32:50