IPv6.connect: only return once any IP address is configured

[hannesm]

This reflects the behaviour of DHCP in the IPv4 stack: we have to temporarily
start the Netif.listen function to potentially receive neighbour
advertisements (and router advertisements etc.), and once an IP address moves
into the PREFERRED state, we signal completion to our caller.

This avoids busy-waiting polling loops in the tests (and all other user code
that first needs to ensure to be able to send out data).

It is not yet clear to me whether this is a sensible and useful solution (esp.
in a dual stack with IPv4 configured by DHCP setup) for the long term, but in
the medium term it is good enough: a IPv6 stack is only useful for transport
layers (UDP, TCP) if we can send and receive datagrams over it.

[hannesm]

now, we should add a test case where a neighbour advertisement is sent as a reply to the ND, and also check this error condition (it should not busy loop (or Ipv6.connect not returning), but rather blow up with some error message -- or try with a different IP address generated).

[MagnusS]

Looks like a reasonable solution to me, at least for now -- it avoids the caller having to add workarounds to wait for the IP after a call to connect and makes the ipv6 stack behave more as ipv4

[hannesm]

@MagnusS I got DAD to work with a FreeBSD host system on the other side (see the last commit for the changes). If this is fine with you, I'd proceed to merge this (though test cases would be good to have as well).

[hannesm]

is there already testing code which injects a packet into vnetif (and awaits an reply packet)? -- EDIT: I think test_icmpv4.ml is a good base to work out some tests for this issue (DAD).

likely there are more error conditions: what if only some IP addresses could be configured, but not all (i.e. only link-local but no global ones)? what if only globals could be configured, but no link local?

[MagnusS]

Changes LGTM and CI is green so merging.