Stop resolver module faults from failing DNS queries

[andylemin]

A review of client-unbound/pfui_unbound.py after an OverflowError appeared on
a live resolver. Nine defects, each ending in a served DNS query being lost, and
each reachable from a configuration an operator can write. Every one has a test
that fails without its fix.

The event name could not be logged

With LOGGING on, every call to operate raised OverflowError from
strmodulevent: its binding rejects a value outside enum module_ev, and the
value pythonmod passes is evidently outside it. A log line must not be able to
fail, so the event is named against the MODULE_EVENT_* constants pythonmod
injects, and an unrecognised value is printed as itself rather than converted —
which will also show what is actually arriving.

An empty FIREWALLS key raised on every answer

FIREWALLS: with its entries commented out parses as None. setdefault
cannot replace a key that exists, so transmit_all iterated None and raised
for every answer carrying an address. The shipped config ships commented-out
entries in exactly that shape. It is normalised at load, with a type check.

The cache callback could poison the interpreter

inplace_cache_callback was the only callback with neither a guard nor a return
value. An exception there discards the cache hit, and the result is read as a
boolean, so returning nothing leaves an error pending for the next query to fail
on. It now returns True and logs what it caught.

A fault at MODDONE looped the query

operate's handler set MODULE_WAIT_MODULE whatever the event. At MODDONE that
tells the mesh to advance and re-enter a module that has already run. A fault
there now finishes the query, as the documented contract requires.

The circuit breaker could never open

Against a firewall that accepts connections and never answers: a cache report
succeeds at the socket, and recording that a success cleared the failures the
blocking path had counted. With any cache hit between two resolutions — the
normal ratio for a resolver — the count never reached the threshold, and every
query kept paying SOCKET_TIMEOUT. Measured: three failures alone open the
breaker, ten interleaved leave it closed with a count of zero. This is the
failure the code's own comment claimed to have fixed. A non-blocking send now
records nothing, because nothing is observable yet.

A reply split in transit was read as a refusal

The acknowledgement was one recv, so an ACKUPDATE delivered in two pieces
compared unequal, logged as a refusal, and was charged to the breaker against a
firewall that had just confirmed the update. It is read until the firewall
closes.

Smaller, same class

• logger's guard against a reply with no records sat five lines after the
  dereference it guarded, and the MODDONE call site tested qinfo where it
  meant rep.
• Numeric config values are coerced once at load and PORT is validated there.
  A quoted '3' reached settimeout() as a string and raised TypeError
  inside the unguarded cache path.
• init_standard now logs a failed callback registration. pythonmod discards
  what init returns, so a resolver would otherwise start with no cache
  callback and whitelist nothing, silently.
• UDP no longer waits for an acknowledgement a failed send cannot produce,
  accepts ACKUPDATE as proof of delivery rather than retransmitting to a
  firewall that has already updated PF, and skips the wait entirely for a cache
  report, which DECISIONS.md defines as fire-and-forget.

Testing

• 234 Python tests, 16 skipped
• Each fix was reverted individually to confirm the matching test goes red
• Two findings rest on how pythonmod treats a callback's return value and module
  states. Both are fixed the way Unbound's own examples do it, so they are right
  regardless, but their severity comes from reading upstream source rather than
  from observing it on a resolver.