ARC shrinking blocks reads/writes

ZFS registers a memory hook, __arc_shrinker_func, which is supposed to
allow the ARC to shrink when the kernel experiences memory pressure.
The ARC shrinker changes arc_c via a call to
arc_reduce_target_size(). Before commit 3ec34e55271d433e3c, the ARC
shrinker would also evict data from the ARC to bring arc_size down to
the new arc_c. However, that commit (seemingly inadvertently) made it
so that the ARC shrinker no longer evicts any data or waits for eviction
to complete.

Repeated calls to the ARC shrinker can reduce arc_c drastically, often
all the way to arc_c_min. Since it doesn't wait for the actual
eviction of data from the ARC, this creates a situation where arc_size
is more than arc_c for the several seconds/minutes it takes for
arc_adjust_zthr to evict data from the ARC. During this time,
arc_get_data_impl() will block, so ZFS can't process read/write requests
(e.g. from iSCSI, NFS, or read/write syscalls).

To ensure that arc_c doesn't shrink faster than the adjust thread can
keep up, this commit makes the ARC shrinker wait for the eviction to
complete, resulting in similar behavior to what we had before commit
3ec34e55271d433e3c.

Note: commit 3ec34e55271d433e3c is `OpenZFS 9284 - arc_reclaim_thread
has 2 jobs` and was integrated in December 2018, and is part of ZoL
0.8.x but not 0.7.x.

Additionally, when the ARC size is reduced drastically, the
arc_adjust_zthr can be on-CPU for many seconds without blocking. Any
threads that are bound to the same CPU that arc_adjust_zthr is running
on will not able to run for a long time.

To ensure that CPU-bound threads can make progress, this commit changes
arc_evict_state_impl() make a voluntary preemption call,
cond_resched().

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: George Wilson <gwilson@delphix.com>
Reviewed-by: Prakash Surya <prakash.surya@delphix.com>
Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Tony Nguyen <tony.nguyen@delphix.com>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
External-issue: DLPX-70703
Closes #10496