We were currently rounding down the result, which could cause the
smoothed RTT to get permanently stuck below the RTT samples.

We now round either up or down, whichever gets us closer to the
current RTT sample.

Note that this slightly increases the amount of information sent out
to the local interface (up to three neighbour updates per received
packet, vs. up to two without this patch).

Disabling the piggyback of timestamps can be useful if the per-message
overhead is not desirable, or for troubleshooting compatibility issues
(there should be none, but who knows).

Note that this commit is a no-op, since this condition is true by
default, and it cannot be set in the configuration yet.

Note that this commit effectively disables the computation of a cost
from the RTT, since 'max-rtt-penalty' defaults to 0.

To do this, we use the timestamps piggybacked on Hello and IHU
messages.

We use a sub-TLV to do so, which we fill out at the very last moment
to get an accurate timing.

This timestamp will be used to compute the RTT to our neighbours.

Note that babeld's behaviour is not modified by this commit.

This will be used to embed a timestamp into Hello messages, which will
eventually allow to compute the RTT between nodes.

parse_msec() is not specific to milliseconds, it can parse any
fixed-point string.  It can be used, for instance, to parse a
fixed-point string written in milliseconds and interpret it as an
integer in microseconds.

The prefix field’s size is Plen/8 rounded upwards.

With large txcost and rxcost, the calculated cost to a neighbour can
exceed 65535, i.e. INFINITY.  This is not a real issue, since any cost
over 65535 is equally seen as infinity.

However, it can confuse other tools (e.g. babelweb) who wouldn't
expect a cost higher than infinity.

This is buggy on OS X, at least. As for linux we choose to be safe and
we deactivate atomic route changes on all BSDs.

This flag is easiest way to filter out babel's route in the
kernel_routes function.

This reverts commit 0845af77.

This prevents a DoS from the local interface, which could be performed
by any user on the system running babeld.

A malicious attacker could connect to the local interface, and then
wait without reading any data.  When the send buffer eventually fills
up, babeld would block; as a result, it would become completely
inoperative.

Note that 'local_server_socket' is already non-blocking, but the
sockets spawned by accept() don't inherit this flag.  From accept(2):

  On Linux, the new socket returned by accept() does not inherit file
  status flags such as O_NONBLOCK and O_ASYNC from the listening socket.

The various cases of success or failure are quite intricate.  Since we
plan to intricate it further in an upcoming commit, it's better to
refactor it now.

We were using the Flags field instead of the AE field when parsing
compressed IPv4 prefixes in Update messages.  This bug shouldn't
trigger, since we never use compression with IPv4.