The manipulation functions are currently static so that the container can be initialized
if required. This will be fixed later.
The new functions are taken into use in monitor management.
Since the settings are now protected fields, all related functions were
moved inside the monitor class. mon_ping_or_connect_to_db() is now a method
of MXS_MONITORED_SERVER. The connection settings class is defined inside the
server since that is the class actually using the settings.
The class MonitorManager contains monitor-related functions that should not
be called from modules. MonitorManager can access private fields and methods
of the monitor.
The functions stores the current server status to the monitored
server's mon_prev_status and pending_status fields.
To be used at the start of the monitor loop, before the pending
status fields are updated.
See script directory for method. The script to run in the top level
MaxScale directory is called maxscale-uncrustify.sh, which uses
another script, list-src, from the same directory (so you need to set
your PATH). The uncrustify version was 0.66.
The master server of a monitor can now be extracted with the
mon_get_external_master function. It uses the REST API to find a master
server in the set of servers monitored by a monitor.
The 'events' and 'script' config values were defined for every monitor.
Removed the extra definitions and moved the variables to MXS_MONITOR.
MariaDBMonitor was printing config values a second time, they are
already printed by the caller.
Moved the events enum definition to the internal header since it's no longer
required by modules.
Added a default config setting "all" to 'events' to clarify that it enables
all events.
The function has use outside of the monitors as it makes execution of
worker tasks much more convenient. Currently, this change only moves the
code and takes it into use: there should be no functional changes.
MariaDBMonitor diagnostics printing is unsafe as some of the read
fields are arrays. To be on the safe side, the fields are now read
in the monitor worker thread.
Since diagnostics must work even for stopped monitors, a worker task
is used. In practice, it usually runs when the monitor is sleeping.
