With unbound 1.11 being first release that switched away from libfstrm (#164, #264), we observe number of regressions with dnstap logging over unix socket.

This one is pretty obvious and relatively easy to reproduce:

* unbound running with dnstap logging enabled over unix socket, under some measurable load (few thousands+ requests per minute)
* dnstap process consuming the logs is restarted.
with 1.9.6, dnstap can reconnect to socket and process samples continuously
with 1.11.0, dnstap can reconnect to socket but receives only 99 samples, all stamped with ~time dnstap process was restarted. Next restart gets another 99 samples, and so on.

Restarting the unbound while leaving dnstap process to run mitigates the problem, until the next time dnstap is restarted.
Unbound's performance seems unaffected.
Doesn't happen when unbound is idle/lightly used.
We observe this on all our Unbound instances with 1.11, never happened on 1.9.6 or earlier versions we used before.