MFC r258076, r258077:

MFC r258076, r258077:

  This fixes 3 problems in syslogd related to sizing receive buffers...

  - A call was misplaced at the wrong level of nested if blocks, so that
    the buffers for unix domain sockets (/dev/log, /dev/klog) were never
    increased at all; they remained at a way-too-small default size of 4096.

  - The function that was supposed to double the size of the buffer
    sometimes did nothing, and sometimes installed a wildly-wrong buffer
    size (either too large or too small) due to an unitialized 'slen'
    variable passed to getsockopt().  Most often it doubled the UDP buffers
    from 40k to 80k because accidentally there would be harmless stack
    garbage in the unitialized variables.

  - The whole concept of blindly doubling a socket's buffer size without
    knowing what size it started at is a design flaw that has to be called a
    bug.  If the double_rbuf() function had worked at all (I.E., if the
    other two bugs didn't exist) this would lead to UDP sockets having an
    80k buffer while unix dgram sockets get an 8k buffer.  There's nothing
    about the problem being solved that requires larger buffers for UDP than
    for unix dgram sockets -- the buffering requirements are the same
    regardless of socket type.

  This change renames the double_rbuf() function to increase_rbuf() and
  increases the buffer size on all types of sockets to 80k.  80k was
  chosen only because it appears to be the size the original change was
  shooting for, and it certainly seems to be reasonably large (I might
  have picked 64k in the absence of any historical guidance).

  Add ENETUNREACH and EADDRNOTAVAIL to the list of errors that are potentially
  transient and shouldn't result in closing the socket and giving up forever.

git-svn-id: svn://svn.freebsd.org/base/stable/10@259368 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f