use ACK/NAK request mechanism to request IPv4 address, (IPv4) DNS/NBNS addresses...

use ACK/NAK request mechanism to request IPv4 address, (IPv4) DNS/NBNS addresses, and IPv6 interface identifiers

The idea is that if we CONFREQ an all-zero value for one of these.
PPP server/peer is supposed to:

- CONFNAK with a value filled in, which we then re-CONFREQ to confirm.
- CONFREJ if it can't supply a value (e.g. NBNS servers because it's
  not 1994 and we're not using Windows for Workgroups 3.11).

Tested with F5, by overriding ppp->solicit_peerns=7, ppp->out_peer_addr.s_addr=0,
ppp->out_ipv6_int_ident=0 in openconnect_ppp_new (even though F5 in fact sends these
addresses in the XML config prior to PPP tunnel).

The CONFREQ/CONFNAK/re-CONFREQ exchange is inefficient, requiring three rounds trips
(request and reject, partial re-request and nak, confirming request and ack), but it
works:

    Sending PPP IPCP Configure-Request packet (id 1, 34 bytes total)
    > 0000:  f5 00 00 1e 80 21 01 01  00 1c 03 06 00 00 00 00  |.....!..........|
    > 0010:  81 06 00 00 00 00 82 06  00 00 00 00 83 06 00 00  |................|
    > 0020:  00 00                                             |..|

    ...

    Received proto 0x8021/id 1 Configure-Reject from server
    Server rejected IPCP request for NBNS[1] server
    Server rejected IPCP request for DNS[1] server
    Server rejected IPCP request for NBNS[0] server

    ...

    Sending our proto 0x8021/id 2 config request to server
    < 0000:  f5 00 00 10 80 57 02 01  00 0e 01 0a e0 a7 1c fb  |.....W..........|
    < 0010:  9e 55 00 00                                       |.U..|
    Sending PPP IPCP Configure-Request packet (id 2, 22 bytes total)
    > 0000:  f5 00 00 12 80 21 01 02  00 10 03 06 00 00 00 00  |.....!..........|
    > 0010:  81 06 00 00 00 00                                 |......|
    No work to do; sleeping for 3000 ms...
    < 0000:  f5 00 00 12 80 21 03 02  00 10 03 06 0a 00 00 17  |.....!..........|
    < 0010:  81 06 5a 9b 5c d1                                 |..Z.\.|
    Received proto 0x8021/id 2 Configure-Nak from server
    Server nak-offered IPv4 address: 10.0.0.23
    Server nak-offered IPCP request for DNS[0] server: 90.155.92.209

    ...

    Sending our proto 0x8021/id 3 config request to server
    Sending PPP IPCP Configure-Request packet (id 3, 16 bytes total)
    > 0000:  f5 00 00 0c 80 21 01 03  00 0a 03 06 0a 00 00 17  |.....!..........|
    No work to do; sleeping for 3000 ms...
    < 0000:  f5 00 00 0c 80 21 02 03  00 0a 03 06 0a 00 00 17  |.....!..........|
    Received proto 0x8021/id 3 Configure-Ack from server
    PPP state transition from OPENED to NETWORK
    Current PPP state: NETWORK (encap F5):
        in: asyncmap=0x00000000, lcp_opts=384, lcp_magic=0x04eb81f9, peer=1.1.1.1
       out: asyncmap=0x00000000, lcp_opts=422, lcp_magic=0x70ac508f, peer=10.0.0.23, solicit_peerns=0

The purpose of the IPv6 interface identifier negotiation is unclear, but the F5
server does not accept a zero value, using CONFNAK to offer a new one.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>