bgpd: verify BGP nexthops' .rgate during each scan

There is a rare, but long-standing issue of IGP nexthop discrepancy with
BGP (both IBGP and EBGP) routes. Whether an original BGP nexthop does
not belong to a connected prefix of the router, bgpd uses
ZEBRA_IPV4_NEXTHOP_LOOKUP message to query (through a cache) a resolved
IGP nexthop ("rgate") for each original BGP nexthop ("gate"), so that
the IGP nexthop and its metric make it into BGP route table ("show ip
bgp"). As soon as such a BGP route is received by zserv (however,
without the resolved IGP nexthop), zebra will attach it to the
respective RIB node, resolving the provided BGP nexthop once again.

The bgpd's nexthop cache is discarded once in a BGP scan interval (5 to
60 seconds), in a way to reprocess all BGP routes for that the resolved
IGP nexthop has changed since the previous scan procedure run. This
addresses IGP changes that made the original nexthop resolve to a
different IGP nexthop (such as from A to B), but misses the cases where
the initial IGP nexthop state matches the eventual one (such as from A
to B to A). Whenever such IGP churn takes place at the time of BGP
prefix feed, some of the routes get installed with the incorrect IGP
nexthop (if B is still reachable) or left "inactive" (if it is not).
Further BGP scan procedure runs don't detect this specific discrepancy,
which can remain in the RIB indefinitely long.

This commit improves the coverage of the scan procedure through an
additional zebra protocol message that is used to copy the contents of
the nexthop cache to zebra process, which verifies that respective RIB
routes are installed using the IGP nexthop matching the one in the
cache. Any prefixes that don't pass the check are signalled to bgpd
using the same message type (but different format). This way bgpd can
schedule such prefixes for reprocessing and limit the lifetime of the
regression with the scan interval.

This solution is based on prior analysis performed by Dmitrij Tejblum
and Vladimir L Ivanov. It has been tested to cause none or little
performance penalty even with a full view BGP table using hundreds of
nexthops.

* lib/zebra.h: add new message type
* lib/log.c: update command_types[] respectively
* bgpd/bgp_nexthop.c
  * recv_verified_desync_prefixes(): new static function
  * send_rgates(): new static function
  * verify_ipv4_rgates(): new static function
  * bgp_scan(): update to take verification results into account
* zebra/zserv.c
  * zsend_ipv4_desync_prefixes()
  * verify_bgp_ipv4_rgates()
  * zread_bgp_ipv4_rgate_verify()
  * zebra_client_read(): update for new message type