Listen for pref64 RA attributes in IpClientLinkObserver.

This allows IpClient to parse the pref64 RA option and put it
in the LinkProperties to be sent to ConnectivityService.

IpClientLinkObserver is a natural place for this because it is
the part of IpClient that is already tasked with receiving
netlink events and storing the results in IpClient's
LinkProperties.

Instead of using the path used by most attributes, which are
parsed by NetlinkHandler, converted to a string array, then
re-parsed and sent over binder call to the networkstack, simply
open a netlink socket in the networkstack process and read the
netlink messages from there. In the future, we can build on this
to parse other netlink messages (e.g., IP addresses, routes,
RDNSS, etc.) in the networkstack and entirely remove the
dependency on netd's NetlinkHandler, which is crufty, hard to
extend, and does not support interface indices.

This means that the pref64 attribute will not be ordered with
respect to other netlink events. This is acceptable because the
pref64 attribute does not need to be ordered with any other
information and its presence or absence does not cause
provisioning to succeed or fail. Today the pref64 is learned
through an entirely different codepath (DNS lookups) and that is
not ordered in any way either.

This CL does not change the threading model: the netlink updates
are processed on the handler thread like all the other updates
seen by IpClientLinkObserver, and all access to mLinkProperties
is synchronized (this). This synchronization is no longer
necessary because everything is on the handler thread anyway,
but that will be cleaned up in a future CL.

Because netlink events contain interface indices, but IpClient
and netd deal with interface names, IpClientLinkObserver must be
told what the interface index is. This is done when
startProvisioning is called, because that is when IpClient
fetches the interface parameters including the MAC address and
interface index. It cannot be done when IpClientLinkObserver is
started, because at that time the interface might not exist, or
might exist with a previous interface index. The interface index
is cleared when IpClient enters the stopped state and the
LinkProperties are cleared.

Bug: 153694684
Test: atest NetworkStackNextIntegrationTests:IpClientIntegrationTest#testPref64Option --iterations 100
Change-Id: I3f8d2fbf2e203c6f90029947fa55b5e0b3b06d94