BFD: consider adding an rx check for control packets with TTL/HL < 255

RFCs section 5881 (single-hop) mentions that TTL/Hop-Limit MUST be set to 255 and MUST be discarded if the value != 255:

5.  TTL/Hop Limit Issues

   If BFD authentication is not in use on a session, all BFD Control
   packets for the session MUST be sent with a Time to Live (TTL) or Hop
   Limit value of 255.  All received BFD Control packets that are
   demultiplexed to the session MUST be discarded if the received TTL or
   Hop Limit is not equal to 255.  A discussion of this mechanism can be
   found in [GTSM].

   If BFD authentication is in use on a session, all BFD Control packets
   MUST be sent with a TTL or Hop Limit value of 255.  All received BFD
   Control packets that are demultiplexed to the session MAY be
   discarded if the received TTL or Hop Limit is not equal to 255.  If
   the TTL/Hop Limit check is made, it MAY be done before any
   cryptographic authentication takes place if this will avoid
   unnecessary calculation that would be detrimental to the receiving
   system.

   In the context of this section, "authentication in use" means that
   the system is sending BFD Control packets with the Authentication bit
   set and with the Authentication Section included and that all
   unauthenticated packets demultiplexed to the session are discarded,
   per the BFD base specification.

We don't do any such checks today, which we should consider doing.

Also of note: this requirement is obviously not present for Multi-Hop BFD (RFC 5883), but a configurable minimum TTL/Hop Limit would make sense as a coarse security mechanism akin to BGP TTL Security.

Start with RFC 5881 section 5 and trace the BFD control-packet receive path; compare the required single-hop behavior with RFC 5883's multi-hop exception. Clarify how authentication affects the check and how a configurable minimum TTL/Hop Limit should work. Done means the scope and configuration behavior are defined and covered by tests.