Eliminate duplicate checks in vdev_geom_io_intr error handling

MFC after:	1 month

(cherry picked from commit dc51a2f9942024cd0123740e86ed23a7253d153c)
Fix ZIO reordering done by vdev_queue_io causing panics when zio_vdev_io_start
returns ZIO_PIPELINE_CONTINUE from vdev_op_io_start to zio_execute resulting
in the wrong ZIO continuing its pipeline.

This is a serious issue which could cause data loss / corruption but appears
to be limited to error handling such as when vdev_readable(vd) returns false.

MFC after:	2 days

(cherry picked from commit 764830753767f22850b41620e71c06c0def1c6ee)
Reintroduce priority for the TRIM ZIOs instead of using the "NOW" priority

The changes how TRIM requests are generated to use ZIO_TYPE_FREE + a priority
instead of ZIO_TYPE_IOCTL, until processed by vdev_geom; only then is it
translated the required geom values. This reduces the amount of changes
required for FREE requests to be supported by the new IO scheduler. This
also eliminates the need for a specific DKIOCTRIM.

Also fixed FREE vdev child IO's from running ZIO_STAGE_VDEV_IO_DONE as part
of their schedule.

As the new IO scheduler can result in a request to execute one type of IO to
actually run a different type of IO it requires that zio_trim requests are
processed without holding the trim map lock (tm->tm_lock), as the free request
execute call may result in write request running hence triggering a
trim_map_write_start call, which takes the trim map lock and hence would result
in recused on no-recursive sx lock.

This is based off avg's original work, so credit to him.

MFC after:	1 month

(cherry picked from commit 14906a620b6524bb6bd3f17265e6c4464f7e31d1)
Removed pointless / duplicated call to trim_map_first.

MFC after:	1 month
X-MFC-With:	r265152

(cherry picked from commit 3b61308dbb51255f9462bdb76f9c2f6d9203fc6c)
Don't treat TRIM requests returning ENOTSUP as an unexpected error.

MFC after:	1 month
X-MFC-With:	r265152

(cherry picked from commit 90763c16795eb165aaad92ff07db5b5a991b4456)
Use a zio flag to prevent recursion of vdev_queue_io_done which can
cause stack overflow for IO's which return ZIO_PIPELINE_CONTINUE
from the zio_vdev_io_start stage and hence don't suspend and complete
in a different thread.

This prevents double fault panic on slow machines running ZFS on
GELI volumes which return EOPNOTSUPP directly to BIO_DELETE requests.

MFC after:	1 month
X-MFC-With:	r265152

(cherry picked from commit fd5ca872534cfb4949b6199db73196121e33e293)
Added sysctls / tunables for ZFS dirty data tuning

Added the following new sysctls / tunables:
* vfs.zfs.dirty_data_max
* vfs.zfs.dirty_data_max_max
* vfs.zfs.dirty_data_max_percent
* vfs.zfs.dirty_data_sync
* vfs.zfs.delay_min_dirty_percent
* vfs.zfs.delay_scale

PR:		kern/189865
MFC after:	2 weeks

(cherry picked from commit 36bcae6396f11d9ca24207f1fb0d104b96a000e0)
Explicitly link libzfs against libavl as it is done in OpenSolaris
(4543:12bb2876a62e).  Without this, some third party applications
may break because the lack of AVL related symbols.

FreeBSD base system are not affected because the FreeBSD ZFS command
line tools were all linked against libavl and thus hide the underlying
issue.

PR:		java/183081
Tested by:	jkim
MFC after:	3 days

(cherry picked from commit 9e29b5f65069140228be54ba30dab6ace4548361)
Fix build: Build libavl as prebuild-lib.

X-MFC-With:	266520
(cherry picked from commit bb351fc8191fffa3ef3dbece90083f303ea976b0)
Improve sysctl descriptions for new ZFS sysctls:
vfs.zfs.dirty_data_max
vfs.zfs.dirty_data_max_max
vfs.zfs.dirty_data_sync

Reviewed by:	smh
Approved by:	wblock (mentor)

(cherry picked from commit 74306fd8a03373eb527b7fddace2198cca881743)
MFV r266766:

Add a new zfs property, "redundant_metadata" which can have values "all" or
"most".  The default will be "all", which is the current behavior.  When set
to all, ZFS stores an extra copy of all metadata.  If a single on-disk block
is corrupt, at worst a single block of user data (which is recordsize bytes
long) can be lost.

Setting to "most" will cause us to only store 1 copy of level-1 indirect
blocks of user data files.  This can improve performance of random writes,
because less metadata has to be written.  In practice,  at worst about
100 blocks (of recordsize bytes each) of user data can be lost if a single
on-disk block is corrupt.

The exact behavior of which metadata blocks are stored redundantly may change
in future releases.

Illumos issue: 3835 zfs need not store 2 copies of all metadata

MFC after:	2 weeks

(cherry picked from commit 78ba1760897362f983b51d564ae721e7355af226)