RPCSEC_GSS type names

[Tom Yu]

This is the first of several messages regarding RPCSEC_GSS.  This
particular message concerns certain type names used in the API.  I'm
working on integrating the UMich RPCSEC_GSS implementation.  Since an
eventual goal is to have a public API, I'm attempting to put the
header files in a state that makes them acceptable for installation.
The gssrpc headers are not currently installed by "make install", as
they contain questionable dependencies on autoconf-generated cpp
macros and possible references to internal headers.

Historical "free" implementations of RPC derive from several source
code releases from Sun.  The one in our source tree derives from
rpcsrc-4.0, which is circa 1988.  This code, as is typical of much
code of the era, distinguishes poorly between implementation and
interface, and also makes unportable assumptions about C types.

A number of functions in the rpcsrc-4.0 API use the "u_long" (BSD
alias for "unsigned long") type to represent certain 32-bit protocol
quantities, such as program and procedure numbers.  In our code, we
have changed some of these to "rpc_u_int32" or something like that.
It would be a good idea to use the C99 type "uint32_t" instead, where
it is available.  (POSIX has mandated uint32_t and related fixed-width
integer types for some time.)

Recent implementations of RPC in Solaris and NetBSD (among others) use
specific types: rpcprog_t, rpcvers_t, etc., for protocol values.
Unfortunately, these seem to have been introduced in tirpcsrc-2.8
(a.k.a. tirpcsrc_99), which I seem to recall has some annoying
conditions in its license that might make it problematic for us to
distribute the code.  I suspect that using simply using the type names
in tirpcsrc-2.8 is safe, though.

I propose using uint32_t and int32_t for most of the places where
rpc_u_int32 and rpc_int32 are currently used.  I also propose using
the rpcprog_t, rpcvers_t, rpcproc_t, rpcprot_t, rpcport_t, and
rpc_inline_t types from tirpcsrc-2.8.

Also, I'm considering defining the BSD type aliases u_int, u_long,
etc. in rpc/types.h on platforms which lack them, so that diffs
against rpcsrc-4.0, etc. aren't quite as annoying to read.  This does
impinge upon the user namespace, but many OSes already define these
aliases anyway (if not compiling with a standards-conforming
namespace).

---Tom