ospfd: Prevent duplicate packet read in certain vrf situations

ospfd:  Prevent duplicate packet read in certain vrf situations

Currently if the sysctl net.ipv4.raw_l3mdev_accept is 1, packets
destined to a specific vrf also end up being delivered to the default
vrf.  We will see logs like this in ospf:

2021/02/10 21:17:05.245727 OSPF: ospf_recv_packet: fd 20(default) on interface 1265(swp1s1.26)
2021/02/10 21:17:05.245740 OSPF: Hello received from [9.9.36.12] via [swp1s1.26:200.254.26.13]
2021/02/10 21:17:05.245741 OSPF:  src [200.254.26.14],
2021/02/10 21:17:05.245743 OSPF:  dst [224.0.0.5]
2021/02/10 21:17:05.245769 OSPF: ospf_recv_packet: fd 45(vrf1036) on interface 1265(swp1s1.26)
2021/02/10 21:17:05.245774 OSPF: Hello received from [9.9.36.12] via [swp1s1.26:200.254.26.13]
2021/02/10 21:17:05.245775 OSPF:  src [200.254.26.14],
2021/02/10 21:17:05.245777 OSPF:  dst [224.0.0.5]

This really really makes ospf unhappy in the vrf we are running in.

I am approaching the problem by just dropping the packet if read in the
default vrf because of:

commit 0556fc33c7275c2a3b00047a536976f8dbf7cbb3
Author: Donald Sharp <sharpd@cumulusnetworks.com>
Date:   Fri Feb 1 11:54:59 2019 -0500

    lib: Allow bgp to always create a listen socket for the vrf

Effectively if we have `router ospf vrf BLUE` but no ospf running
in the default vrf, we will not have a listener and that would
require a fundamental change in our approach to handle the ospf->fd
at a global level.  I think this is less than ideal at the moment
but it will get us moving again and allow FRR to work with
a bunch of vrf's and ospf neighbors.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>