The Listener::create method now takes a set of configuration parameters
from which it constructs a listener. This removes the duplicated code and
makes the behavior of listener creation similar to other objects in
MaxScale. It also allows the configuration parameters to be stored in the
listener object itself.
It is an error to register the same task multiple times, but
for a maintenance release it is simpler and less risky to simply
ignore an attempt (that BLR does) to do that.
Allowing a task to be registered anew causes behaviour akin
to a leak.
This makes iterating over packets in buffers faster while still
maintaining the requirements for forward iterators. Not using operator+=
makes it clear that this is not a random access iterator.
If there have been any changes in the bootstrap servers specified
for the Clustrix monitor, then the persistent connection information
is not used.
Otherwise, if the bootstrap server is changed and inaccessible, we
may connect to another cluster than the intended one.
Persisted information about dynamic nodes must be used only if
the bootrap information has not been changed, as otherwise we risk
using information that is not valid.
The functions that searched for listeners compared both sockets and
addresses in the same function. This made its use error prone and caused
false positives in some cases.
"Once you eliminate the impossible, whatever remains, no matter
how improbable, must be the truth." Arthur Conan Doyle
Since server objects are never destroyed, currently the only
explanation for the crash described in MXS-2446 is that a server
created at runtime could not, immediately after the creation, be
found using its name.
If the nodes change while a multi HTTP GET is in process, the
corresponding delayed called must be cancelled. Otherwise we
eventually would end up attempting to update the state of the
nodes using the wrong result.
