Fix non initialized usage of data in zebra_rnh.c

Fix non initialized usage of data in zebra_rnh.c

In zebra_deregister_rnh_static_nexthops the nh_p
structure was not being properly initialized for
all the cases that we could be storing a nexthop
for.  This was causing code later to retrieve
the table from an nh_p->family which was garbage.

In the case of BLACKHOLE and Ifindex based routes
do nothing because they shouldn't be a nexthop
considered for NHT.

==2239== Conditional jump or move depends on uninitialised value(s)
==2239== at 0x4E5F6CE: family2afi (prefix.c:217)
==2239== by 0x155F7C: get_rnh_table (zebra_rnh.c:83)
==2239== by 0x156194: zebra_lookup_rnh (zebra_rnh.c:148)
==2239== by 0x15655E: zebra_deregister_rnh_static_nh (zebra_rnh.c:242)
==2239== by 0x156681: zebra_deregister_rnh_static_nexthops
(zebra_rnh.c:280)
==2239== by 0x12F3DF: rib_unlink (zebra_rib.c:2210)
==2239== by 0x12E9CE: rib_process (zebra_rib.c:1843)
==2239== by 0x12EA8A: process_subq (zebra_rib.c:1873)
==2239== by 0x12ECAF: meta_queue_process (zebra_rib.c:1936)
==2239== by 0x4E89625: work_queue_run (workqueue.c:298)
==2239== by 0x4E63230: thread_call (thread.c:1577)
==2239== by 0x125830: main (main.c:432)
==2239==
==2239== Conditional jump or move depends on uninitialised value(s)
==2239== at 0x4E5F6DB: family2afi (prefix.c:220)
==2239== by 0x155F7C: get_rnh_table (zebra_rnh.c:83)
==2239== by 0x156194: zebra_lookup_rnh (zebra_rnh.c:148)
==2239== by 0x15655E: zebra_deregister_rnh_static_nh (zebra_rnh.c:242)
==2239== by 0x156681: zebra_deregister_rnh_static_nexthops
(zebra_rnh.c:280)
==2239== by 0x12F3DF: rib_unlink (zebra_rib.c:2210)
==2239== by 0x12E9CE: rib_process (zebra_rib.c:1843)
==2239== by 0x12EA8A: process_subq (zebra_rib.c:1873)
==2239== by 0x12ECAF: meta_queue_process (zebra_rib.c:1936)
==2239== by 0x4E89625: work_queue_run (workqueue.c:298)
==2239== by 0x4E63230: thread_call (thread.c:1577)
==2239== by 0x125830: main (main.c:432)

Ticket: CM-10667
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Shrijeet Mukherjee <shm@cumulusnetworks.com>