Refactor angular features enablement

[Travis Tripp]

LAUNCH_INSTANCE_NG_ENABLED & LAUNCH_INSTANCE_LEGACY_ENABLED
were added as new feature toggles in Kilo. We added multiple
spots on the python code that looks it up in a rather non-declarative
and non abstract way. We also just created a generic settings
angular service. This worked, but now we are thinking about
ways to standardize on this concept so that a common features
API on the Python side and angular side can be used abstract
looking up whether or not a feature is enabled. This provides
better abstraction and isolation between code that needs to know
if a feature is enabled or not and will allow more standardization
or logic in the future to determine whether or not a feature is enabled
with less likelihood of having to rewrite all existing code.

This is not intended to replace all existing settings in settings.py.

For example, current feature lookup on python side looks like this:

getattr(settings, 'LAUNCH_INSTANCE_LEGACY_ENABLED', True):

It would be better if we can simply say:

features.enabled('LAUNCH_INSTANCE_LEGACY', True)

Similarly on the angular side, you inject a settings service which has a pretty direct binding to the underlying python settings. Using and injecting a Feature service will allow us to use different methodologies in the future without having to change code. It will provide an abstraction layer.

To support standard settings service lookups, we will create a common features area under local_settings.py with the following structure:

FEATURE = {
    'LAUNCH_INSTANCE_NG': {
        'enabled': True,
    },
    'IDENTITY_USERS_TABLE_NG': {
        'enabled': True,
    }
}

This will enable simple lookup using a python utility or the angular settings service via a helper function.

This structure will enable much richer future fields to be added to describe the feature, its status, etc. e.g.:

FEATURES = {
    'LAUNCH_INSTANCE_NG': {
        'enabled': True,
        'description': 'super cool next gen launch instance',
        'status': 'beta'
    }
}

Initially, all that will determine if a feature is enabled will be the 'enabled' toggle. But in the future other fields or logic could be used without disturbing the code the uses the feature utils or featureService.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/179545

[OpenStack Infra (hudson-openstack)]

Change abandoned by Travis Tripp (<email address hidden>) on branch: master
Review: https://review.openstack.org/179545