(it didn't make sense before this branch, but now it could cause regression
as we remove the 'new' qualifier).

in some cases we can't simply use 'new' (but normally safe without it),
and in some cases we need additional synchronization points to make it
work more reliably.

previously the semantics was a bit ambiguous and resulted in some
less predictable behavior. (and, non suprisingly, some usage cases
in features seem to be wrong about "wait for new").

As the only test that is being run in the system tests from xfrin.

The porting is not exact, we don't build the differences in bind9. We
provide them in a database already - we don't want to rely on bind9 and
bind10 can't build differences as of yet from master files (eg.
ixfr-from-differences).

It just does two queries and compares the output.

reviewed by jelte via jabber.

Changes some log message descriptions and some
function arguments and some output.

initialize message loader in PyInit_datasrc.
Updated one of the general lettuce tests to check the symptom (don't know how else to test this tbh)

Do a hack to make the tests run with separate build and source
directories. The generated file ended up in a different directory than
the rest of the modules and the __init__.py. It therefore didn't work.
We use the same trick as log_messages, a forwarder module and addition
to PYTHON_PATH to find it.

Only the real file is installed.

Logging XFRIN_TRANSFER_PROTOCOL_ERROR as INFO level message could be
confusing. Rename to XFRIN_TRANSFER_PROTOCOL_VIOLATION, which is
neutral which has a neutral name regarding the log levels.

The old version with . didn't work well with the form
  wait … for MESSAGE not OTHER_MESSAGE
Since the whole "MESSAGE not OTHER_MESSAGE" was captured into the first
(.+). This broke several tests in around xfrin and possibly others.

Now the tests pass and reviewed on jabber.

it didn't work if only 'counter' parameter is given

Check the new version is rejected and the old one is still available.

Provide a zone without NS and see it rejects it.

This actually found a bug, maybe unrelated.

Check the data in existing tests produce warnings, but the data is still
accepted.

because its counter would probably return 0 or 1 depending on timing

This way we check the logging works to the correct place and that the
configuration is handled. It is better checked by lettuce than unit
tests, since there's a lot of inter-module communication in it.