"Debug" option for config table

User Story

As a user, I want to be able to fetch the functional values for configuration properties even if no value has been explicitly assigned, to better understand the system's default operation.

Also, as a team member, I'd like to assemble a comprehensive list of all config variables for documentation purposes. I've done some codebase scraping to start myself on this track, but in a recent meeting it was suggested to me that this task may flow more smoothly if we had a way to query defaults, or at least dump all possible variables to log.

Acceptance Criteria

The main suggested solution to this was to create a debug method that would perform a log dump of the system's config table, including default values.

A way to query an individual variable may also prove useful to someone performing tests — maybe something similar to api/v1/system-table's GET, though probably not that method exactly, since the system table also can hold arbitrary keys. Thus, extending or overloading system-table GET would require a couple of extra boolean properties in the response object to indicate whether the current value is equal to the default, and whether the stored key corresponds to a configuration property at all. So, maybe something separate from system-table would be better. I'm just thinking out loud, though; the log-dump idea is the main thing.

Proposed Objective

Documentation

Proposed Priority

Priority 3 - Average

Start by reading the existing api/v1/system-table GET behavior and how the configuration table distinguishes stored values from defaults. The issue's main proposed outcome is a debug log dump containing configuration variables and functional default values; an individual-variable query is only exploratory. Done means the chosen interface and its treatment of defaults are defined and documented, with no ambiguity about whether arbitrary system-table keys are included.