refs #71, #65

The reasons are discussed in #71.
Namely:
- transfers are self-paced, TCP clients are divided among threads
- due to the nature of DNS, most of the connections should be active
- if not, it is probably an attack, long idling connections are disconnected
- even then the performance degradation is not so severe

fixes #71

Otherwise it would finish all pending queries, some of which may have
connection already dropped. This usually isn't a problem, it just
presents a longer wait for the timeouts.

Existing issues must not be treated as expired, since that might
trigger bootstrap requeue or NOTIFY event.

This is because the query should be sent as soon as the socket is
writable as well.

refs #65

It was possible for the previous implementation to sometimes overshoot
the hard limit by a few connections, this yielded very undesirable results
as the master starts dropping connections and forcing slave to reschedule
transfers.

Asynchronous connect is also faster as other pending transfers may be processed
during the connection phase.

refs #65

refs #65

To do:
* Disabled epoll/kqueue backend as there is something broken for write events

refs #65

    - This assert made no sense, flow can get into this function even if previous is set. In fact, previous is used in the function that is called just after said assert.
Previous was set to NULL in previous implementation, which was wrong as well.

RRSIGs for DS RRSets in answer section used to be added to authority section.

Refs #73

refs #54

- Should be substantially faster for "hit" lookups.

Marek Vavrusa authored 11 years ago and Jan Včelák committed 11 years ago

prev 3202195c

1. when no 'log' section is configured, defaults apply
2. when 'log' section is configured & empty, no logging occurs
3. stderr & syslog do not automatically log fatal errors

fixes #61

issue #67

issue #64