LINUX: Use sock_create_kern where available

Currently, we use sock_create to create our Rx socket. This means that
accesses to that socket (sendmsg, recvmsg) are subject to SELinux
restrictions. For all recvmsg accesses and some sendmsg accesses, this
doesn't matter, since the access will be performed by one of our
kernel threads (running as kernel_t or something similar, which is
unrestricted). Such as: the rx listener, a background daemon, the rx
event thread, etc.

However, sometimes we do run in the context of a normal user process.
For some RPCs like FetchStatus, we tend to run the RPC in the
accessing user thread, which can result in us sendmsg()ing the data
packets with the initial arguments in the user thread. We can also
send delayed ACKs via rx_EndCall, and possibly a variety of other
scenarios.

In any of these situations when we are sendmsg()ing from a user
thread, SELinux can prevent us from sending to the socket, if the
calling user thread context is not able to write to an afs_t
udp_socket. This will result in packets not being sent immediately,
but the packets will be resent later, so access will work, but appear
very slow. This can easily happen for processes that are specifically
constrained by SELinux; for example, webservers are often constrained,
even if most of the rest of the system is not. This can be noticed by
seeing the 'resends' and 'sendFailed' counters rising in 'rxdebug
-rxstat', as well as noticing SELinux access failures if 'dontaudit'
rules are ignored.

To avoid this, use sock_create_kern to create the Rx socket, to
indicate that this is a socket for use by kernel code, and not
accessible by a user. This should cause us to bypass any LSM
restrictions (SELinux, AppArmor, etc). Add a configure check for this,
since this function has not always existed, according to
<https://lists.openafs.org/pipermail/openafs-devel/2004-June/010651.html>

Change-Id: I77e7f87e93be4d750d398e01dc1634efd80657bc
Reviewed-on: http://gerrit.openafs.org/10594
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>