Add afsconf getkey variants for RXGKFS

That is, getkey routines for use by fileservers.

Fileservers will keep their token-encrypting keys in KeyFileExt,
using a new key type afsconf_rxgk_fs.  Such keys are only used
if no keys of type afsconf_rxgk are present (that is, the cell-wide
key takes precedence, both at token-decyryption time and at
vlserver-registration time).

Also fix some whitespace nits where the KeyFileExt key types
are defined.

Change-Id: Ife585cc976ffe1b1f86d9f285f3be9e599c75c29
Add afsconf_BuildFileServerSecurityObjects

Make use of the new getkey routines for per-fileserver keys, but
only if there are no cell-wide keys available.

Change-Id: I0cd3b7c5654c113f18c0a49c6e7bd84b2b5edfb7
rxgk support for viced

Use afsconf_BuildFileServerSecurityObjects to get our security
objects; introspect to see if there is an rxgk object in the
output, so that we can use rxgk.

If we have rxgk capability, use an rxgk connection to the vlserver
to register our addresses.  Only printed tokens from the cell-wide
key are currently supported, and we do not support registering
per-fileserver keys.  (For one, the vldb has no way of recording
that we are rxgk-capable yet.)

While here, make a file-local routine static.

The use_rxgk flag should arguably be a part of the configuration
directory state, but that can wait for later.

Change-Id: I067ce991e69cb2b2752e6808573489a0aa4f5e3c
Implement SRXGK_AFSCombineTokens

This functionality requires a way for the vlserver to be able to lookup
the token-encrypting key for a given fileserver UUID.  To do this from
the rx security class directly would be a layering violation; rxgk
cannot depend on the vlserver directly.  Instead, supply a callback
as service-specific data, which gives a routine to retrieve a key
for encrypting tokens to a given UUID.

No implementations of this getfskey hook are provided in this commit;
the vlserver's implementation will come in a later commit.

Change-Id: Icd955202c92a3665e1e827b81687e17a2a28638d
Add getfskey argument to BuildDBServerSecurityObjects

Will need to hook this into the server security object somehow,
and this seems the least ugly at the moment.

Change-Id: Ic70ea18ab8eef4b4231c3f3ed68aabe15190111d
vlserver: use an rxgk getfskey routine

In order for SRXGK_AFSCombineTokens to function properly, the rx
service providing that RPC must attach service-specific data
allowing the lookup of a token-encrypting key for a given fileserver
UUID.  This commit provides a very simple implementation of that
getfskey functionality for the vlserver.

In particular, it only supports fileservers that have the shared
cell-wide key, and only fileservers that are colocated with
database servers.  This is because it is required for a database
server to have the cell-wide key for operation, and so a fileserver
on that same host must also have access to the cell-wide key.
Since no released version of this software has database servers that
implement rxgk but fileservers that do not implement rxgk, if
rxgk is enabled, we can assume that the fileserver software supports
rxgk and has access to the shared cell-wide key.

This is the best functionality that can be supplied reliably
without changes to the vldb format (which would mark whether
individual file servers are rxgk-capable, and what key to use
for them).

Change-Id: I6f7afe34c2ec5e99e7b1b3984a92d1dda6eda2de
Data types for in-kernel rxgk tokens

We will only be able to use the GetTokens2 and SetTokens2 variants,
which use XDR to encode/decode data across the pioctl boundary.
Since userspace only needs to use these types immediatly around pioctl,
it can use the XDR-produced types directly, but these data types are
rather clunky for regular use in the kernel.

As such, define additional types for use in the kernel, as is done
for the existing rxkad functionality.

The XDR types for pioctl use should only be used for dbserver
tokens; userland should not be acquiring fileserver tokens for
kernel use, and the kernel should not be caching fileserver tokens
where they might get returned to userland.  This allows us to
preserve the invariant that a TokenJar has only one token per
user per cell per token type.

In order to make the XDR types for rxgk tokens dependent on the
configure option --enable-rxgk, we must include afsconfig.h in
token.xg for use by rxgen's preprocessor.  This requires some
tweaks to work everywhere, since afsconfig.h can bring in sys/types.h,
which on some systems has typedefs that are not compatible with
RPC-L typedefs.
In-kernel pioctl handlers for rxgk tokens

Use the new data types to implement functionality for using
rxgk tokens with GetTokens2 and SetTokens2.  The structure is
basically parallel to the existing rxkad handling.

Change-Id: I1089488bbb26fa56bd6d6b011b2c4b62beaf912d
Add gklog; insert rxgk tokens into the kernel

This is mostly a stub implementation with very minimal
functionality.  All of the nice things that aklog provides
(log to paths, log to multiple cells, .xlog, etc.) are not
supported; this is just a way to do functionality testing
at the moment.

Keep the old copyright from the aklog code this started from, and
update the date for the new work.  (Same rightsholder, imagine that.)

Ideally it would be possible to factor out most of aklog into
something that can be reused for rxgk, but that is probably a
fair amount of work.

Change-Id: I83c9a6b5646dcbaa692df535ba3965b8b4309f2d
tokens: display rxgk tokens

Pretty minimal output, for now.  The rxgkTime expiration
time is not converted to a more human-friendly format.

We do not currently store anywhere on the client the client's
GSSAPI identity which is embedded in the token, so it is
only possible to print the viceid (if present) for now.

Change-Id: If79b919e64e47ae79a966a2df6a5b0f898bff6db
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
Note a location where future work is needed

Change-Id: I7590fc5b354aead1373476cea2d2af876b535689
rx: Do not try to cancel nonexistent events

Unconditionally cancelling the resend event and releasing the
reference it was supposed to have on the call, can cause the
call reference count to go negative.

In particular, the call chain when a new rx_call structure is
allocated would cause its reference count to become negative.

Behave similarly to all the other rxevent_Cancel calls touched
by 20034a815750beff262d49b37fba225c72dd0ab1, and only cancel the
event and drop a reference when the event is present on the call.

Change-Id: Icf2dd58c2545814ac17bb960077621c6d3209da0
rxgk for hpr

Change-Id: I0ca63181793cf01ec2bc0664373d10821152b851
BuildFileServerSecurityObjects for volser, too

Change-Id: I2c4446bac5b9db90d57e2993bd0ebcb379736d4b
Note the ClientAuth calls and why we can't do more

Change-Id: Id98dca61c44afc7c1b6ad817fb609dff9187a4f3
viced support rxgk tokens

We get rx_identities out from rxgk_GetServerInfo; convert
back to PrAuthName and fire off queries to the ptserver.

(Our ptserver is not capable of serving the necessary RPCs yet.)

Change-Id: I883ef1dc67498f00eedc1464c595c42184eb077b