Deflake and fix testIpClientClearingIpAddressState.

This test is flaky (at least when run on device) because often
IpClient is started before it has heard about the IP address that
the test adds to the interface. Then, when provisioning is
started, it succeeds immediately because due to historical
reasons the presence of an IPv4 address is sufficient to declare
a network provisioned.

Attempt to configure the address in a way that will avoid this
sort of race. Because IpClient does not expose information about
its inner state, or send any callbacks while it's stopped, do
this by tapping in to the same observer registry that the test
IpClient instance uses, and adding two addresses on the
assumption that when the second one is observed, all observers,
including IpClient, will have seen the first one be added.

Also, the test was not very realistic. It configured an IPv4
address, and then ran DHCP, and expected that the IPv4 address
would be cleared by ClearingIpAddressesState. But DHCP clears
the address as well, because netd only supports configuring one
IPv4 address per interface, so the test is not very useful. Use
IPv6 instead.

Bug: 139314310
Bug: 152723363
Test: atest NetworkStackIntegrationTests:IpClientIntegrationTest#testIpClientClearingIpAddressState --iterations 100
Change-Id: Ibf2fa0260df313c604ec0be3d04f49319f02d60e