We now accept v4-via-v6 routes if the kernel supports installing
them, and announce them if the kernel is able to source ICMPv4
without an IPv4 address.  The latter behaviour is configurable,
the former is not.

A node with no IPv4 addresses may still be able to forward
IPv4 packets.

Its polarity is changed, and it also controls incorrectly signed packets.

Introduced by 3b3813fad09eb694a508789394679b6d3378d472.

It wasn't consistent with the naming of other option. The option is
phrased positively to match the Information Model (babel-mac-verify).

Thanks to Julien Muchembled for finding a bug in a previous version of
this commit.

Nodes with default mac-verify would not accept packets from nodes with
non-default mac-verify.
Co-authored-by: Julien Muchembled <jm@jmuchemb.eu>
Co-authored-by: Antonin Décimo <antonin.decimo@gmail.com>

Don’t call `start_message()` since it may cause an infinite loop.

The exact narration is implemented, with all the specified
optimisations.

- neighbour creation is delayed;
- if multiple PCs are found, only the first one is processed, the
  remaining ones are be silently ignored;
- a node ignores all challenge requests contained in a packet except
  the last one;
- and it ignores a challenge request in the case where it is contained
  in a packet with an Index that matches the one in the Neighbour Table
  and a PC that is smaller or equal to the one contained in the
  Neighbour Table.

s/crypto seqno/pc/g
s/challenge response/challenge reply/g
s/challenge req/challenge request/g

Macros starting with __ are reserved for the implementation, it should
not appear in code.

We used to accept packets signed by any key.

This was completely wrong.