Fix a bug in the client side krpc where it was, sometimes
erroneously, assumed that 4 bytes of data were in the first
mbuf of a list by replacing the bcopy() with m_copydata().
Also, replace the uses of m_pullup(), which can fail for
reasons other than not enough data, with m_copydata().
For the cases where it isn't known that there is enough
data in the mbuf list, check first via m_len and m_length().
This is believed to fix a problem reported by dpd at dpdtech.com
and george+freebsd at m5p.com.

Reviewed by:	jhb (for head)
Approved by:	re (kib)

Fix the krpc so that it can handle NFSv3,UDP mounts with a read/write
data size greater than 8192. Since soreserve(so, 256*1024, 256*1024)
would always fail for the default value of sb_max, modify clnt_dg.c
so that it uses the calculated values and checks for an error return
from soreserve(). Also, add a check for error return from soreserve()
to clnt_vc.c and change __rpc_get_t_size() to use sb_max_adj instead of
the bogus maxsize == 256*1024.

Make the RPC specific __rpc_inet_ntop() and __rpc_inet_pton() general
in the kernel.

Sponsored by: Sandvine Incorporated

Add mutex locking for the call to replay_prune() in
replay_setsize(), since replay_prune() expects the
rc_lock to be held when it is called.

If the first iteration of the do loop in replay_prune()
succeeded and a subsequent interation failed to find an
entry to prune, it could loop infinitely, since the
"freed" variable wasn't reset to FALSE. This patch moves
setting freed FALSE to inside the loop to fix the problem.

When the regular NFS server replied to a UDP client out of the replay
cache, it did not free the request argument mbuf list, resulting in a leak.
This patch fixes that leak.

PR:	kern/144330

Make options KGSSAPI build and add it to NOTES.

rpcsec_gss_prot.c:
  Use kernel printf and headers.

vc_rpcsec_gss.c:
  Use a local RPCAUTH_UNIXGIDS definition for 16 instead of using NGROUPS.

  Replace the static NGROUPS=NGROUPS_MAX+1=1024 with a dynamic
  kern.ngroups+1.  kern.ngroups can range from NGROUPS_MAX=1023 to
  somewhere in the neighborhood of INT_MAX/4 one a system with sufficent
  RAM and memory bandwidth.  Given that the Windows group limit is
  1024, this range should be sufficient for most applications

r202342:
  Only allocate the space we need before calling kern_getgroups instead
  of allocating what ever the user asks for up to "ngroups_max + 1".  On
  systems with large values of kern.ngroups this will be more efficient.

  The now redundant check that the array is large enough in
  kern_getgroups() is deliberate to allow this change to be merged to
  stable/8 without breaking potential third party consumers of the API.

201408,201325,200089,198822,197373,197372,197214,196162). Since one of those
changes was a semicolon cleanup from somebody else, this touches a lot more.

  (S)LIST_HEAD_INITIALIZER takes a (S)LIST_HEAD as an argument.
  Fix some wrong usages.
  Note: this does not affect generated binaries as this argument is not used.

  PR:		137213
  Submitted by:	Eygene Ryabinkin (initial version)