Update to BIND-8.2.3-TB5

[Mark Kettenis]

I've basically done all the work to update the resolver to
BIND-8.2.3-TB5.  This is the current beta release, and
< http://www.isc.org/products/BIND > says that "This is prerelease code
and is not intended for production use."  However, the announcement
says that it is a release candidate, and the code contains some bug
fixes and real improvements, so I'm pretty confident that we can
safely use this code.  And I intend to closely track the official BIND
distribution and update glibc accordingly.

However there are some things I'd like your opinion on:

* I've tried to reduce the diffs with the official BIND sources to a
  minimum.  This means that my patch will contain some gratitious
  white-space changes and that I've reintroduced __P is <resolv.h>.
  The rationale being that it is easier to spot any real changes when
  imporing a new BIND version.

* I've changed all RCS $Id$ strings into $BINDId$.  This should
  prevent CVS from doing its keyword substitution, such that we retain
  the origional version information.  Again this makes it easier to
  spot which files have been changed in BIND with respect to the
  previous import.

* I've changed the implementation of how the resolver behaves in a
  multi-threaded context as follows:

  1. The "old" thread-unsafe interfaces (e.g. res_init(), res_query(),
     res_search() etc.) always act on a static resolver state (the
     global variable _res).

  2. All threads, except the main thread, have their own resolver
     state, and _res is a macro that uses the function __res_state()
     to get the per-thread resolver state.  The main thread continues
     to use the static resolver state in the global variable _res
     (which is normally hidden by the _res macro).

  The motivation for this setup is that it makes it possible to use
  legacy code that uses the "old" interfaces in the main thread
  without any problems (including setting _res.options before calling
  res_init()).  Solaris has a similar restriction.  Even code that
  sets _res.options in the main thread and calls the "old" interfaces
  in other threads will still work as expected if locking is used to
  prevent two threads from concurrently using the static resolver
  state.  Modifying _res.options in other threads will seem to have no
  effect when using these "old" interfaces.

  To be really thread-safe, programs should use the new interfaces of
  course.  The macro _res is there for their (and our, since we use it
  in the dns NSS module) convenience to avoid the need of allocating
  their own.

  Of course this was already how Andreas implemented things, except
  that for some curious reason he modified res_libc.c such that
  res_init() now uses the thread-specific resolver state, whereas the rest of
  the old functions still use the static resolver state.  That cannot
  be right, and I think that's why people noticed some problems.

  If people agree with this, I'll try to wrap up some documentation.

* BIND-8.2.3-TB5 uses a double underscore on all exported functions.
  Are there strong reasons not to do this?  If not, I'll add an alias
  for the old symbols that didn't have the double underscore and
  additionally export the double underscored version, and I'll export
  those new functions that are documented in the resolver(3) man page
  that comes with BIND-8.2.3-TB5 with a double underscore.  I think
  this might avoid some problems with programs that link with libbind
  (which also contains the reolver code and use our dns NSS module.

  The alternative is to export all documented symbols without the
  double underscore, and add aliases for those symbols that were
  previously exported with a double underscore.

Mark