module can identify clients based on their source address or used TSIG
key

the requestor can provide information identifying the query originator
here (address and TSIG key), both fields are optional
update Lua FFI bindings

this is a small step for me, but a huge step for resolver

based on _BSD_SOURCE timersub macro

this fixes stats for canceled/blocked or forwarded queries without
started name resolution

this also fixes static linking missing a math library

this is a first step of leaning towards LuaJIT.
the FFI bindings are much faster, simpler and don’t abort traces

daemon core scripting engine is still going to support interpreted Lua, but modules requiring library bindings (such as ‘block’) will require LuaJIT for FFI

previously the pointer for C layer API was stored in Lua, it is stored directly in module data now for fast access. this doesn’t disturb VM when processing requests.

this provides a useful callback for per-request operations that can’t wait until the query is completed (e.g. blocking or logging started queries)

the memory could go through the roof with sufficiently high pps, GC now runs at 4x the speed of allocations and doesn’t wait for increase, some callbacks also perform full collection cycle on completion

if the configured modules name is prefixed with ‘<‘ it takes precedence before all others,
e.g. modules = { ‘hints’, ‘<block’ }
means that the ‘hints’ module will be executed in-order (last), and ‘block’ module layer will be called as first in query processing

calling a Lua layer now takes only O(1) registry lookup and
pushing the right parameters

this is a saner default for large answers. instead of waiting for
probably lost/thrown away fragmented packet, do the query over TCP
instead

fixed CID#125374

this fixes a problem when a module was removed, but pending
queries referenced it, causing a crash. usually when the
server was busy and a module was unloaded.
as we don’t need to copy layers at all, they’re just iterated
from the array of modules using a macro