bgpd: With suppress-fib-pending ensure withdrawal is sent

When you have suppress-fib-pending turned on it is possible
to end up in a situation where the prefix is not withdrawn
from downstream peers.

Here is the timing that I believe is happening:

a) have 2 paths to a peer.
b) receive a withdrawal from 1 path, set BGP_NODE_FIB_INSTALL_PENDING
   and send the route install to zebra.
c) receive a withdrawal from the other path.
d) At this point we have a dest->flags set BGP_NODE_FIB_INSTALL_PENDING
   old_select the path_info going away, new_select is NULL
e) A bit further down we call group_announce_route() which calls
   the code to see if we should advertise the path.  It sees the
   BGP_NODE_FIB_INSTALL_PENDING flag and says, nope.
f) the route is sent to zebra to withdraw, which unsets the
   BGP_NODE_FIB_INSTALL_PENDING.
g) This function winds up and deletes the path_info.  Dest now
   has no path infos.
h) BGP receives the route install(from step b) and unsets the
   BGP_NODE_FIB_INSTALL_PENDING flag
i) BGP receives the route removed from zebra (from step f) and
   unsets the flag again.

We know if there is no new_select, let's go ahead and just
unset the PENDING flag to allow the withdrawal to go out
at the time when the second withdrawal is received.

Signed-off-by: Donald Sharp <[email protected]>
(cherry picked from commit 4e8eda7)

bgpd/bgp_route.c

@@ -3482,6 +3482,12 @@ static void bgp_process_main_one(struct bgp *bgp, struct bgp_dest *dest,
 					 BGP_PATH_ATTR_CHANGED);
 		UNSET_FLAG(new_select->flags, BGP_PATH_MULTIPATH_CHG);
 		UNSET_FLAG(new_select->flags, BGP_PATH_LINK_BW_CHG);
+	} else {
+		/*
+		 * Ensure that on uninstall that the INSTALL_PENDING
+		 * is no longer set
+		 */
+		UNSET_FLAG(dest->flags, BGP_NODE_FIB_INSTALL_PENDING);
 	}
 
 	/* call bmp hook for loc-rib route update / withdraw after flags were