Read or delete autowired routes on startup

[DarthGandalf]

Followup to #30

If ndppd segfaults for any reason, and gets restarted, the previously added routes will never get deleted? ndprbrd handles this case by "protocol 100", and reading such routes from the routing table upon startup.

@john-sharratt

ndprbrd deletes them after the expiration period. It may be easier to delete them immediately on startup, but then in the first minute IPv6 connectivity may be more broken.

[CasperVector]

OpenWRT's odhcpd does not maintain the expiration table itself, but relies on the kernel's neighbour table and the assumption that ICMPv6 is not filtered by the hosts involved: it does not relay NSs and NAs by itself, but pings the destination address on network segment(s) other than the source segment; it then watches the neighbour table for changes, and sets up entries for said address in the NDP proxy table as well as the routing table accordingly. This mechanism also seems to be an alternative way to solve the issue which resulted in the creation of ndprbrd.
I have just slimmed down the odhcpd codebase (which also takes care of DHCPv6 and router discovery, and uses OpenWRT's libubox and UCI which are not widely adopted elsewhere) to ease integration in regular Linux distros. If you intend to implement a similar mechanism in ndppd, the spin-off might be of some interest. However, do note that the odhcpd codebase is GPLv2 only and therefore cannot be copied directly into ndppd which is GPLv3+; additionally, the codebase relies on libnl and epoll(), which makes it unportable outside of Linux.
A shortcoming of odhcpd's mechanism is that, depending on when the NDP proxy entry is setup, the first NS/NA packets might appear to be dropped. Additionally, this mechanism is still vulnerable to a rare race condition: if an entry was removed from the neighbour table when odhcpd is somehow not running, the corresponding entries in the NDP proxy table and the routing table would not be deleted; however, this seems much less likely to occur than the problem you mentioned.