Implement the rxgk server routines

Provide non-trivial implementations of the security class routines
used by the server, along with helpers as necessary.

In addition to the normal NewServerSecurityObject routine, provide
wrappers NewServiceSecObj and NewEphemeralService_SecObj that create
the security object, create an rx service for the key negotiation service
needed for clients to negotiate tokens useful with this server security
object, and register the getkey function used for the security object
as service-specific data to be used when encrypting tokens produced by
this rx service.  The Ephemeral variant creates a random token-encrypting
key for use by the service, so no getkey routine needs to be supplied
by the caller.

The identity supplied in a client's token is given as a list of
PrAuthNames; we assume that at most one name is supplied at present,
as the meaning of compound identities (and the use of compound
identities for keyed cache managers) is not fully specified yet.
Convert the PrAuthName to an rx_identity for caching in the server
connection state, as the rx_identity type is more compatible with
superuser checks on the connection.

Also provide an rxgk_GetServerInfo routine which extracts the cached
identity, for use in libauth when making superuser checks.
This moves our dependency on rx_identity from the private data structures
into the public header, so move the nested include accordingly.

Change-Id: I0f48b69d4ab758d8a4d76ebfb1daf3009c4fe060
Implement rxgk client security object routines

Also add rxgk_NegotiateSecurityObject, a routine that creates
an rxnull connection to a target server, obtains a token using
the GSSNegotiate RPC on that connection, and uses the resulting
token to make an rxgk connection to that same server.

Change-Id: Ic7e11b02cb1573cfdb6d11d4de9a77ab1c563262
Implement SRXGK_CombineTokens

Most of the logic we need is already in place in rxgk_token.c; we just
need to pull out the token data structures, combine the identity lists,
and call into that code.

Change-Id: I68dd5dffab579d89601a55b8ed82961f8e12fc1b
Build rxgk support into libafsrpc

This is done rather differently for the shared and static libafsrpc
forms.  For the shared library, we can add a dependency on the shared
$(GSSAPI_LIBS) and link in liboafs_rxgk.la directly.  libafsrpc_rxgk.la
(which only has stubs for the rxgk GSS-using routines) is linked into
the static library, so that it remains useful for statically linking
applications.  Consumers of libafsrpc.a need not be modified in
accordance with this change.

Change-Id: I76c0329ba842fb0d4d66534810b114a0813c90a0
BuildServerSecurityObjects allocate for rxgk

Don't do anything with it for now, just leave a place in the
array.

Change-Id: I304e0f6bcf7d3b2a2cb46c976f41e09809a436db
Let superuser identities be superusers

We have a special rx_identity_kind for superusers, let it actually
be useful for something.

Change-Id: I1d551ed8e5fcfd6bdc29c6c27eee4c2ae67e1a89
Add rxgk support to userok

Sprinkle @RXGK_LIBS_STATIC@ as needed to keep LWP bits building.

Change-Id: I5da2a89532453b6bec61fc87218a61455e39f6f0
Implement afsconf_GetRXGKKey

Also afsconf_GetLatestRXGKKey, as a side effect, since we want to have
a single getkey function both for getting encrypting and decrypting keys;
a kvno/enctype pair of 0/0 indicates that the "get latest" behavior is
desired.

This also requires implementing an ordering on the quality of the
different RFC 3961 enctypes (which are stored as the subtype of keys
of type afsconf_rxgk).  This is ... pretty awkward to code up, and
also subject to debate on the actual ordering.  Since the IANA enctype
registry changes rarely, just assign a full ordering on the standardized
(symmetric!) enctypes, giving integers as the ordered values, and
store that in a constant array.  Then, the lookup table allows the
comparison of the strength of enctypes ~directly.

Provide stubs for KERNEL use; UKERNEL builds this file but does not
have any real rxgk support yet, so fails to link due to the
missing rxgk_make_key symbol.

Sprinkle some @RXGK_LIBS_STATIC@ to keep the LWP bits building and
add the corresponding dependencies on @RXGK_TARGET@.

Change-Id: I81389b21238fd6588cc4381b026816005f81a30c
Add afsconf_BuildUbikServerSecurityObjects

This new interface is specifically for use in building the server
security objects that will be used to handle ubik-internal connections
(that is, DISK_ and VOTE_).

This is the normaml set from BuildServerSecurityObjects, with a custom
rxgk server security object.  The only tokens used for ubik-internal
communication are printed tokens, so the rxgk key negotiation service
(RXGK_) should not be provided.  afsconf_GetRXGKKey is used as the
getkey function for these connections, since the cell-wide rxgk key
from KeyFileExt is used for them.

Change-Id: Id332aabcf80ed35bda36dcce92e762d46b590f47
Use afsconf_BuildUbikServerSecurityObjects for vl, ptserver

Accept rxgk tokens for incoming intra-ubik connections.

Change-Id: I31dca8c8db4dada1a5d3f9b193e7506fdf6ece47
Add afsconf_BuildDbServerSecurityObjects

Used to build the server security objects for database servers that
will accept the actual user RPCs (for the VL and PR services, etc.).

Change-Id: I59e6bce2c1ccf8c873bda913b28f26d9c2a49f63
Use afsconf_BuildDbServerSecurityObjects for the vl, ptserver

Change-Id: I713d78384f4d6347b17104a97ad72650ac363491
Add afsconf_ClientAuthRXGK

Always encrypts, eliminating the need for a separate 'Secure' variant.
On modern hardware the AES we'll end up doing should be faster than
our rx stack can keep up with.

Change-Id: Ib27f2799eb927ac5aa71eab94212171344dd93df
Add -rxgk option to vlserver, ptserver

Optionally use rxgk for ubik server-to-server connections, via
afsconf_ClientAuthRXGK.  All the db servers in the cell must have
been upgraded to a version that accepts rxgk ubik connections before
this option can safely be enabled.

Change-Id: Iefae46291330d2b5e05b2a2bbaec1b9150b3c892
DO NOT MERGE

A snapshot of the pthread-bos bits, all squashed together.
Done so that subsequent commits adding rxgk support to bos/bosserver
can be pushed to gerrit without using a merge commit or adding a
fake dependency chain to one of the patch series.

This snapshot is as of 267a362efb262e79eefc684cf6cddf5241443498.

Change-Id: I0245d598c12dc09a52da5cea26be2104cb826958
Register bosserver for rxgk

Add the server security object, using an ephemeral token-encrypting
key.  We rely on the local hostname being correctly set (and lowercase!)
to match the afs3-bos hostbased service acceptor identity.

Since we are adding a new service, set the number of processes that
will handle that service.

We need to add the GSSAPI CPPFLAGS to the CFLAGS for this module, as we
are not including the gssapi headers.

Change-Id: Ibacf16993d67349c59986ca3c62a0293c723ca67
Check for krb5_get_init_creds_opt_set_out_ccache

The forthcoming bos/rxgk/localauth code will use it.
I am told that the routine it is used in is only needed for MIT krb5,
as Heimdal's gssapi library will fetch initiator credentials from the
default keytab by default.  Since set_out_ccache is only provided
on MIT krb5, that is rather fortuitous.

Change-Id: I68576ea791f6f2253e082b23bb3a82e6bb624bc4
bos: add support for rxgk

While rxgk is experimental, add a new argument -rxgk to attempt
the use of rxgk.  -localauth is supported by using the acceptor
credentials as an initiator and self-negotiating.

afsconf_PickClientSecObj doesn't know about rxgk yet, so we need
to have our own separate control flow for the rxgk case.  This
will be fixed eventually, but it's not clear what the right API
for PickClientSecObj is, yet.

Change-Id: I7af099cfe53c844f96959c904c33ca632c0d3e57
Add afsconf_rxgk_fs

To be used to hold per-fileserver keys in the KeyFileExt.

Also fix some whitespace while here.

Change-Id: I2fabc178909ae119298ff2db6ebc8737aa882736
Start on viced

Change-Id: I067ce991e69cb2b2752e6808573489a0aa4f5e3c