Implement foreign volume handling.  Allows admins to view foreign metadata
and clear or import it for use.

PR:     kern/172091
Submitted by:   smh@freebsd.org
Reviewed by:    jhb@freebsd.org
MFC after:      2 weeks
Merge in changes from NetBSD:
 * Remove support for non-elf files.
 * Add the VFP setjmp magic numbers.
 * Add the offsets for the VFP registers within the buffer.
cxgbe/tom: Fix bad signed/unsigned mixup in the stid allocator.  This
fixes a panic when allocating a mixture of IPv6 and IPv4 stids.

MFC after:	1 week
MFV r251519:

 * Illumos ZFS issue #3805 arc shouldn't cache freed blocks

Quote from the Illumos issue:

    ZFS should proactively evict freed blocks from the cache.

    Even though these freed blocks will never be used again, and thus
    will eventually be evicted, this causes us to use memory
    inefficiently for 2 reasons:

    1. A block that is freed has no chance of being accessed again, but
       will be kept in memory preferentially to a block that was accessed
       before it (and is thus older) but has not been freed and thus has
       at least some chance of being accessed again.

    2. We partition the ARC into several buckets:
       user data that has been accessed only once (MRU)
       metadata that has been accessed only once (MRU)
       user data that has been accessed more than once (MFU)
       metadata that has been accessed more than once (MFU)

    The user data vs metadata split is somewhat arbitrary, and the
    primary control on how much memory is used to cache data vs metadata
    is to simply try to keep the proportion the same as it has been in the
    past (each bucket "evicts against" itself).  The secondary control is
    to evict data before evicting metadata.

    Because of this bucketing, we may end up with one bucket mostly
    containing freed blocks that are very old, while another bucket has
    more recently accessed, still-allocated blocks.  Data in the useful
    bucket (with still-allocated blocks) may be evicted in preference to
    data in the useless bucket (with old, freed blocks).

    On dcenter, we saw that the MFU metadata bucket was 230MB, while the
    MFU data bucket was 27GB and the MRU metadata bucket was 256GB.
    However, the vast majority of data in the MRU metadata bucket (256GB)
    was freed blocks, and thus useless.  Meanwhile, the MFU metadata bucket
    (230MB) was constantly evicting useful blocks that will be soon needed.

    The problem of cache segmentation is a larger problem that needs more
    investigation.  However, if we stop caching freed blocks, it should
    reduce the impact of this more fundamental issue.

MFC after:	2 weeks
  Separate LIO_SYNC processing into a separate function aio_process_sync(),
and rename aio_process() into aio_process_rw().

Reviewed by:	kib
Sponsored by:	Nginx, Inc.
  Make sys_mlock() function just a wrapper around vm_mlock() function
that does all the job.

Reviewed by:	kib, jilles
Sponsored by:	Nginx, Inc.
Add proper __sync_*() intrinsics for MIPS.

To make <stdatomic.h> work on MIPS (and ARM) using GCC, we need to
provide implementations of the __sync_*() functions. I already added
these functions for 4 and 8 byte types to libcompiler-rt some time ago,
based on top of <machine/atomic.h>.

Unfortunately, <machine/atomic.h> only provides a subset of the features
needed to implement <stdatomic.h>. This means that in some cases we had
to do compare-and-exchange calls in loops, where a simple ll/sc would
suffice.

Also implement these functions for 1 and 2 byte types. MIPS only
provides ll/sc instructions for 4 and 8 byte types, but this is of
course no limitation. We can simply load 4 bytes and use some bitmask
tricks to modify only the bytes affected.

Discussed on:	mips, arch
Tested with:	QEMU
Use improved __sync_*() intrinsics for MIPS in userspace as well.

r251524 introduced custom tailored versions for MIPS of these functions
for kernel-space code. We can just reuse them in userspace as well.
  Add new system call - aio_mlock(). The name speaks for itself. It allows
to perform the mlock(2) operation, which can consume a lot of time, under
control of aio(4).

Reviewed by:	kib, jilles
Sponsored by:	Nginx, Inc.
aio_mlock() added:
  - Regen for r251526.
  - Bump __FreeBSD_version.
sigaction(2): Document various non-POSIX functions as async-signal safe.
Import Kevin Lo's port of urtwn(4) from OpenBSD. urtwn(4) is a driver for the
Realtek RTL8188CU/RTL8192CU USB IEEE 802.11b/g/n wireless cards.
This driver requires microcode which is available in FreeBSD ports:
net/urtwn-firmware-kmod.

Hiren ported the urtwn(4) man page from OpenBSD and Glen just commited a port
for the firmware.

TODO:
- 802.11n support
- Stability fixes - the driver can sustain lots of traffic but has trouble
coping with simultaneous iperf sessions.
- fix debugging

MFC after:	2 months
Tested by:	kevlo, hiren, gjb
Actually make the 2-byte atomics work.

Even though I tested the 1-byte operations on arbitrarily aligned bytes,
it seems I did not do this for the 2-byte operations.

Create easy to read functions that are used to get/put bytes and
halfwords in words. To keep the compiler happy, explicitly read two
bytes into a union to obtain a 16-bit value.
Remove extraneous characters ('<<<') from `Exit' menutag in the "Security"
and "Startup"->"Misc" modules to make the menus appear more consistent with
the numerous other modules and look a little cleaner.

PR:		ports/169316
Reduce verbosity in the "Console"->"Saver" module (bsdconfig syscons_saver)
by replacing the infinitive [verb] phrase "Simply blank the screen" with a
simple description of what you get; "Blank screen".

PR:		ports/169316
Fix a regression in the "Login Management" module introduced by r251242 in
which choosing to cancel the manual input of expiration time (in seconds
since the UNIX epoch) for either account expiration or password expiration
would see the original value lost.
Track defaultitem in the password and account expiry menus; if the user
presses ESC or chooses Cancel/No in any of the sub-menus, we want to return
to the expiry menu with that item selected.
Check for ESC as a separate choice from "NO" when asking if the operator
would like to disable password management for an account while adding either
a user or group. When being prompted to answer questions while adding a
group or user, two things are trow:

1. You can hit ENTER to blast through all the questions and in the end, the
   group or user is created with sensible defaults for all values.

2. You can press ESC during any prompt to cancel the operation as a whole.

This fix is shoring up an inconsistency in the latter (#2).
Fix a regression introduced by r251544; if user chooses "NO" when being
asked if they would like to disable password authentication for the account,
loop back to prompt them for the password again.
Update locking scheme, mostly transition from sched_lock.