Test for the hard fetchlimit instead of soft fetchlimit

Test for the hard fetchlimit instead of soft fetchlimit

Previously, the fetchlimit tested the recursive-clients soft limit
that's defined as 90% of the hard limit (the actual configured value).
This worked previously because the reaping of the oldest recursive
client was put on the same event queue as the current TCP client, thus
the cleaning has happened before the new TCP client established a new
connection.

With the change in BIND 9.14 that added a multiple event queues the
cleaning of the oldests clients is no longer synchronous and could
happen stochastically making the soft limit testing fail often.  The
situation became even worse with the new networking manager, thus we
change the system test to fail only if the hard limit bound is not
honored.

Changing the accounting of the already reaped TCP clients so the soft
limit testing is possible again is out of the scope for this change.