This would cause an assertion failure whenever we
sent a Unicast Hello.  Thanks to Dave Taht.

  * clarify code flow, only checking for future state once
  * clarify error messages when MTU is guessed by including the MTU value

As suggested by Christof Schulze.

It's a minor optimisation, but it makes me happy.

If no Hello has been buffered yet, insert an unscheduled Hello.
This only works if rfc6126-compatible is false.

This just implements the sending functions, it doesn't actually do anything
with them yet.

This fixes the case where a neighbour only sends unscheduled Hellos.

Incorrect message size when neighbour is not link-local.

Now that we have sub-TLVs and crypto keys, the previous value is no longer
suitable.

`if_conf` can be null if the allocation fails in line 520.

Set the version to be "unknown" when the git repository does not contain
any tags.

Only allocate the neighbour after all the basic sanity checks have been
performed.  This is important in the HMAC branch.

This slows down initial convergence, but avoids a broadcast burst
at boot.  Thanks to Teco Boot for pointing this out.

The purpose is to override *locally* RTA_PREFSRC ('src' in ip-route).

This is only a cleanup and not a functional change

Source prefix can be specified only once.

It was removed by accident in commit ce457a79.

DTLS has recently changed to disallow unprotected IHU, so we now
need to send IHU over unicast.

What was I thinking?

Since this causes flushbuf to take a struct interface, we're basically
carrying a struct interface all over the place.  Good.

Avoid the duplication by passing around an interface pointer.

src_plen for IPv4 routes imported from kernel has not been adjusted
to v4mapped encoding. Therefore IPv4 xroutes used an inconsistent encoding
which lead to failed comparisons when sending updates.

Routes received from neighbors with the same prefix as xroutes therefore
have been announced to neighbours instead.

This issue is fixed by converting src_plen on import.
Signed-off-by: Fabian Bläse <fabian@blaese.de>