Revamp config

[lars-t-hansen]

This is sort of a metabug. Related are #532, #495, #401, #413, #443, #440, #97.

The cluster config info is currently hand-maintained with the help of some ad-hoc scripts. In addition to the cluster-config.json file there is a system config file per cluster, and optionally a background information file that is combined with sysinfo from the cluster to produce that system config file. It barely hangs together, crucially does not handle the time-dependency of config data, and requires manual intervention.

The new database architecture tries to clean this up with the "cluster", "config", and "node" tables but it's not a complete job.

Really what we want here:

• the "config" table is time-dependent and append-only, so that one can look up the config of a system at a point in time
• a new "background" table can be time-dependent and sort of append-only, or at least it can be insert-by-timestamp, this would add info not available through sysinfo
• config information is then formed from background info and sysinfo (latest available for the node for a given date in question). in effect config becomes a report, not a table (in the sense that jobs is a report, not a table).
• probably config information of this type would have to be cached internally, with basic cache invalidation

Older implementation notes:

we would push background info per node (maybe sonalyze could do node list and expand it?) and every record would have to be complete info for the node, records would never be combined, so the workflow would be read-amend-push where the push

would append the record with a new timestamp, we might require the timestamp to be sensible? or would we just insert in db by provided timestamp? and prune by equal timestamps so that we have a total timeline per node?