Manage App Settings in the database

[slominskir]

Many apps that use smoothness have custom app settings stored in a Settings table. Providing a generic Setting database table and interface for editing would consolidate a lot of code. All of the the smoothness weblib settings are actually environment variables at the moment. A DB store of settings is generally better than using environment variables because:

• Can be changed without restarting Wildfly
• Type checking can be performed (limited somewhat if using generic key-value table). We can store in DB with check constraint of Y or N boolean types at least...
• Can tie a description field with the variable directly
• More transparent for casual admins if they can view/edit on the interface
• Declutters the README and declutters the very long .env file needed for Wildfly - instead just indicate settings with descriptions can be browsed under Setup/Settings tab.
• Creates separate namespaces per app in a cleaner way. Often multiple apps are deployed on a single Wildfly instance, sharing the same environment variables. To work around this we namespace envs with an app prefix. We expect an app prefix is defined in web.xml and then rely on concatenating that prefix when doing env lookups. This complexity goes away if we just rely on the database that all smoothness apps already have.

Environment Variables are better when:

• You don't have a database
• You want to use the same value for multiple apps in a given env
• You share the database between multiple environments and want different settings per env

[slominskir]

Probably makes sense to make user-authorization-cache linked in Setup tab more prominently. The Setup tab tag file might need to be configurable based on List from Setting table or something. EJB-service level annotation for roles allowed to edit settings probably needs an alternative approach like programmatic role check from Settings table or something.