deal with inet_pton that doesn't recognize AF_INET6

[jinmei]

I've received a feedback from a user who tried to build and used BIND 10.
The OS is CentOS6 (reportedly), disables IPv6 in the kernel, and
apparently its inet_pton doesn't recognize AF_INET6 (not sure it's
related to the kernel support of IPv6; API-wise it should be
independent).

This caused at least two known issues:

• some test data (generated by src/lib/util/python/gen_wiredata.py) can't be generated because the genetator script fails to create AAAA rdata.
• b10-resolver (and I suspect b10-auth also) failed to start up because its default config has ::1/53 for listen_on, which is considered a syntax error.

I'm not sure whether we want to help such environment; it seems to me
inet_pton that doesn't recognize AF_INET6 is so broken and wouldn't
be worth introducing another layer of complexity in our code. But if
such a deployment is actually not so uncommon, we may have to do
something in our side.

Based on discussions at the Mar12 2013 team call, specific suggestion
is:

• Do #2842 (this will "hide" the first problem for most ordinary users)
• Document the second issue with workaround somewhere

Regarding the second (the main task of this ticket), my suggestion is
to update the description of SRVCOMM_EXCEPTION_ALLOC log message which
currently reads:

The process tried to allocate a socket using the socket creator, but an error
occurred. But it is not one of the errors we are sure are "safe". In this case
it is unclear if the unsuccessful communication left the process and the bind10
process in inconsistent state, so the process is going to abort to prevent
further problems in that area.

This is probably a bug in the code, but it could be caused by other unusual
conditions (like insufficient memory, deleted socket file used for
communication).

so it will mention the issue. As a workaround we should be able to
avoid it by editting the installed resolver/auth.spec excluding IPv6
addresses from listen_on. We document it there, too. And provide
some text in ChangeLog?.

[jreed]

Also see #2628 (duplicate?)

[tomek]

As part of bug scrubbing during Kea 1.0, we decided to move a number of tickets to DHCP Outstanding.

[tomek]

Milestone renamed

[tomek]

Hi, it's 2016. We should actually check the opposite - if Kea can build and run on IPv6-only system :)