This clarifies what parts of the router are specific to the binlogrouter
and what are common between the binlogrouter and avrorouter.
Ideally, the two modules would use the same infrastructure to handle the
processing of replication events. This is the first, albeit small, step
towards making the code in the binlogrouter the common infrastructure.
According to customer reports collecting the statistics has a significant
impact on the performance. As we don't need that information we can just
as well turn off that.
Further, since maxscale-common now links to the sqlite3-library, no
module needs to do that explicitly.
The test loads multiple modules in one call so we have to pre-load them
one by one to make sure that they are all present regardless of the
locations where the individual modules were built.
The internal header directory conflicted with in-source builds causing a
build failure. This is fixed by renaming the internal header directory to
something other than maxscale.
The renaming pointed out a few problems in a couple of source files that
appeared to include internal headers when the headers were in fact public
headers.
Fixed maxctrl in-source builds by making the copying of the sources
optional.
The `user`, `password`, `version_string` and `weightby` values should be
allocated as a part of the service structure. This allows them to be
modified at runtime without having to worry about memory allocation
problems.
Although this removes the problem of reallocation, it still does not make
the updating of the strings thread-safe. This can cause invalid values to
be read from the service strings.
All modules now declare a name for the module. This is name is added as a
prefix to all messages logged by a module. The prefix should help
determine which part of the system logs a message.