Create feature toggle for analytics, stream, and task endpoints

[markpollack]

As a developer, I would like to individually enable/disable the analytics, stream, and job controller features. This will enable users to

• Avoid dependency on Redis if there is no need to use analytics functionality (common for batch centric use-case deployments)
• Not expose additional endpoints if they are not to be used, e.g. current spring-batch-admin users that would like to use SCDF's UI/endpoints and not be exposed to any stream API/concepts. Similar case for stream only users.

The features would be defined by the config

spring:
  cloud:
    dataflow:
      features:
        analyticsEnabled: true
        streamsEnabled:  true
        tasksEnabled: true

by default. Tasks support includes job support.

A features/ endpoint will need to be created to will indicate which features are enabled/disabled so the UI/Shell can take the appropriate actions. There is similar information for security already exposed under /security/info - we should consolidate the security information to be serves up under the features endpoint as well even though security is not configured under the features yaml section.

There will be related issues to handle this on a per-server basis and for the UI/Shell and also for PCF and Mesos servers so that task support is overridden to be false.

Only when enabling tasks or streams would corresponding schemas be created in the database, otherwise no schemas would be created.

[markfisher]

Would it make sense to consider using profiles? In any case, perhaps the UI could just consult the existing /env endpoint to find the properties.

[markpollack]

The /env endpoint isn't something that is normally exposed (''sensitive' = true by default) and it probably would expose more than we want such as database usernames/password. Though profiles could work in as much as we just have boolean values.

I was thinking that we might want this to be a bit more first class in the naming as I was reading through http://www.togglz.org/ They do have a bit of a strange binding there - see the end of http://www.togglz.org/documentation/spring-boot-starter.html for some yaml.

[ghillert]

Profiles are certainly possible also. but we also need to serialize the features via the rest endpoint. Thus, maybe having a Boot compatible Features configuration classes would make sense here in regards to usability. So you have 1 class that encapsulates the features. With profiles it seems like we will have different data representations to deal with.