Revert "bgpd: bgp_scan shouldn't queue up route_nodes with no routes for processing"

Revert "bgpd: bgp_scan shouldn't queue up route_nodes with no routes for processing"

This reverts commit ff75b6c05bb9ca1b9c4c48f2231fd4cbfd393b17.

lib/table.c's route_common() can create a rn for a prefix that BGP has
never RXed.  For example here we RX 10.1.8.0/24 from neighbor 10.0.0.2,
notice how the 10.1.0.0/20 entry is created.  We would later assert on
this prefix because its info was NULL.

2016/06/16 23:37:21.418426 BGP: 10.0.0.2 rcvd UPDATE w/ attr: nexthop 10.0.0.2, origin i, localpref 100, metric 0, community 99:7, path
2016/06/16 23:37:21.418442 BGP: 10.0.0.2 rcvd UPDATE wlen 0 wpfx 0 attrlen 36 alen 4 apfx 1
2016/06/16 23:37:21.418458 BGP: bgp_node_create called
2016/06/16 23:37:21.418475 BGP: route_node_get called for 10.1.8.0/24, route_node_new 10.1.0.0/20, match (nil)
2016/06/16 23:37:21.418519 BGP: bgp_node_create called
2016/06/16 23:37:21.418536 BGP: route_node_get called for 10.1.8.0/24, route_node_new(2) 10.1.8.0/24, match 0x2013cd0
2016/06/16 23:37:21.418554 BGP: 10.0.0.2 rcvd 10.1.8.0/24

If rn->info is NULL then avoiding the group_announce_route() call in
bgp_proces_main() also feels risky as this code path generates WITHDRAWs
for prefixes that no longer have a bestpath which would be the case if
there are no paths.