Commit a62b7c9b was broken in that
2 nodes with same id/hmac settings could not communicate when
1 of the 2 has no_hmac_verify.

To be pushed upstream.
Co-authored-by: Julien Muchembled <jm@nexedi.com>

TODO: documentation

To be pushed upstream.
Co-authored-by: Julien Muchembled <jm@nexedi.com>

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

We used to accept packets signed by any key.

This was completely wrong.

Also rename DIGEST_LEN to MAX_DIGEST_LEN.

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

Flag to allow empty or wrong hmac in the packet trailer.

Known issues:

  - we create a neighbour entry before the first successful challenge;
  - we compute HMAC for each HMAC TLV rather than just once;
  - we only support sending one HMAC TLV;
  - we don't support key rotation.
Co-authored-by: Clara Do <clarado_perso@yahoo.fr>
Co-authored-by: Weronika Kolodziejak <weronika.kolodziejak@gmail.com>

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.