Add database persisted settings handling

[wintondeshong]

In most projects we inevitably need a means to store settings in the database, as opposed to application settings/env vars. Referencing gravity boots and/ or other projects. Add settings actors (ie. conductors, entity, mappings, etc...).

[shaneshearer]

Unsure of the thought around strategy, but in some projects, we tend to make a significant number of calls to get these settings. Depending on what is being stored for these settings, it may make sense to store them in application state, local storage or cached on the server. Eliminating the potential number of requests and/or database hits as much as possible while not allowing the data to get too stale.

[wintondeshong]

Agreed that we do tend to call settings, and honestly other shared tables, too often. Developers should take caution and limit their reading from the DB (or other external sources) in whatever ways best suits their use case. That said, it is risky and error prone from a user experience perspective to just have the settings code do caching out-of-the-box by the boilerplate. While I wish we could have a one-size-fits-all performance tuned conductor for all use cases out of the box, unfortunately the "age" and strategy for caching can vary by each individual setting itself.

In terms of where to cache, efforts to cache on the server should be first objective. Leaving that choice to the frontend client isn't enough. Even if we are the only ones consuming the API.

[shaneshearer]

Thanks for the reply @wintondeshong! I just wanted to make sure it was noted!