WL#8462: Plugin(s) to test services of server

To support the implementation of plugins there exist services (APIs) like 
"my_snprintf" or "my_plugin_log_message". To test these services systematically
one or more plugins will be needed. A kind of test frame work or example
plugin(s) shall be provided to show how tests for services can be implemented.
Goal is to run these test plugins with mtr. That allows to assure( and show) the
interaction between plugin, plugin service and SQL.

FR1: The test plugin must be a normal plugin to install/uninstall in mtr tests
(as usual), preferably one of the existing plugin types.

FR2: The results of tested services must be visible in mtr result files.

FR3: A test plugin must be provided serving as example.

FR4: The example test plugin must be extendable by adding more test cases for
services.

FR5: A minimal frame work for new test plugins for services must be available as
base for implementing new test plugins.

As base for the test plugin on server side the daemon plugin type can be taken.
It will be loaded (started) with the sql statement "INSTALL PLUGIN" and unloaded
(stopped) by calling "UNINSTALL PLUGIN". There is no other communication between
server and daemon unless it will be explicitly implemented e.g. with the help of
an API or service. INSTALL and UNINSTALL will be executed by a mtr test. It may
of course contain other sql statements. 
The plugin shall write its test results into one or more files. These files can 
then be written into the result file of the mtr test with the normal mtr
commands like "cat_file". 
The plugin can also write messages into "mysqld.1.err". These messages can be
made visible in the result file or checked as follows: Load this log into a
table with 2 columns (date, info). Info will be selected by removing '\r' to be
compatible to windows (The err log file on windows contains CR,LF as newline).
Select the messages so they will be visible in the mtr result file. A perl
snippet can be used for that purpose, too.
In a plugin status and system (sql) variables can be specified. With status
variables the state of the test execution can be reported to the mtr test
calling the test plugin. That might be useful to e.g. give a ready message for a
test case or the whole plugin. Especially when using threads in a test plugin
such status variables are useful to synchronize execution of plugin and mtr test
as both are running in parallel.
System variables can be used to e.g. control test execution. But, that is very
rudimentary as it is more kind of configuration at start of the plugin.

The test plugin consisting of
- the directory "test_services" to put into plugin directory
- the mtr test "test_services.test" and the result file to put into main.

Test_services contains the "test_services.cc" showing how to test services, here
"my_snprintf" and "my_plugin_log_message". For each of the services there is a
function implemented containing the test cases (actually not complete). Instead
of using the standard I/O of C++ it is much more comfortable to used "my_open",
"my_write", etc. as it covers all platforms.
The output of "my_snprintf" can be found in "var/mysqld.1/data/test_services.log".
"my_plugin_log_message" writes into "mysqld.1.err".
The (selected) contents of these files can be seen in the result file of
"test_services.test".
"test_services.test" didn't create a thread. The effect is that the test
(mysqld) is waiting until the plugin completes its work. A waiting condition is
basically not necessary. 
The plugin "test_service_threaded.cc" runs the tests in a thread. This needs
synchronization of plugin and mtr runs as both are running in parallel. The
synchronization will be done by waiting for the plugin (exactly the thread in
the plugin) to be finished. If the thread is needing a very long time then the
mtr test may run in a timeout.
The test plugin "test_framework.cc" is a rudimentary implementation of a daemon
plugin, which can be take to create new one. It might be better to copy one of
"test_services" examples and modify it, depending of the need of threads or not. 
Using threads has the advantage of limiting test execution with a timeout. That
may be interesting for long running plugins testing complex API tests. Plugins
needing a short run time may run without threads.