I noticed that the king's text log file kept filling up, and it's
mostly 'sending chunk "\n"' from eyre. This changes the log level
of every partial send over an active eyre channel to info, instead
of always.
Slightly simplify the logic around changing the queue size counter by
only modifying it when we're _actually_ scrying, instead of
synchronously processing the forward.
While stateless forwarding doesn't need to touch disk, there's still
overhead in needing to communicate with the serf over IPC. By caching
lanes, we get to skip the IPC pipeline, and can respond to forwarding
requests synchronously.
We include timestamps alongside the entries in the cache, and consider
entries older than two minutes as stale.
The cache is capped at around ~100mb of memory use. Further commentary
is provided inline.
Previously, ~nus would drop 3 forward requests, for every one it
fulfilled. Now, it seems able to keep up with demand, only dropping
forwards shortly after boot, while the cache isn't primed yet.
Instead of giving up on scrying at the first sight of a u3_none result,
keep trying for a little bit. If five scries fail in direct succession,
consider scrying not worth the effort, and stop trying as before.
Previously, if ames told us there was no lane for a target, we would
drop the packet, but fail to register this in the queue, or even reclaim
the memory it was using.
Now, we do all the required book-keeping when dropping packets in the
"no lane for this" case.
This fixes a case where the natpmp async could pure () instead of
recursing, which would lock ames. This also adds some more error
handling on the haskell side of things and disables the raw fprintfs
in the c bindings layer.
Since startup hangs for seconds when you are not behind a router,
but still attempt to ask one to open ports for you, by default,
only try to contact the router if the local ip is 192.168.*.* or
10.*.*.*.
Also make port forwarding force on/off.
