The output generated by a failed call to a module command was previously
overwritten with the error messages stored in the module command
subsystem.
In the case of a failure, the proper procedure is to check if the output
generated by the module command conforms to the JSON API error
specification and if it does, combine it with any system generated error
messages. If the output does not conform, it is stored in the "meta" field
of the returned object. This allows all of the generated output to be
saved.
Using commas instead of spaces prevents a the misinterpretation of
commands as hostnames. If the `--hosts` option was given just before a
command, it would consume the commands as arguments to the `--hosts` list.
Only asynchronous authenticators require the thread-specific loading of
users as the synchronous ones all share the same data. If the service does
not declare asynchronous capabilities at startup, the users are not
seeded. This prevents unnecessary loading of users at startup.
If node00 is not the master when a test is started, the cleanup
performed by TestConnections takes considerable time.
By restoring the sitation back to normal before ending the test,
the startup time of the next test can be shortened significantly.
Time elapsed is now properly tracked during a switchover. After slave
redirection, an event is added to the master. Then, the slaves are queried
repeatedly until they advance to the newest event. I/O and SQL errors are
also detected.
Now that mariadbmon supports failover and switchover, a test may
may change the master to some other node than node 0.
Consequently, as part of fixing the replication, gtid_slave_pos
of node 0 must be reset as well.
As the stale status is not a real status bit and it's used to retain the
history of a master, there is no need to print it in any output. This
output will only confuse users now that the stale status will not be
cleared from masters that go down.
