MFC r258353: zfs page_busy: fix the boundaries of the cleared range

This is a fix for a regression introduced in r246293.

vm_page_clear_dirty expects the range to have DEV_BSIZE aligned boundaries,
otherwise it extends them.  Thus it can happen that the whole page is
marked clean while actually having some small dirty region(s).
This commit makes the range properly aligned and ensures that only
the clean data is marked as such.

It would interesting to evaluate how much benefit clearing with DEV_BSIZE
granularity produces.  Perhaps instead we should clear the whole page
when it is completely overwritten and don't bother clearing any bits
if only a portion a page is written.

Ticket: #3506

(cherry picked from commit 8aca8c335b91220e069331e6fff73b8ad65186d0)
MFC r258389: MFV r258378: 4089 NULL pointer dereference in arc_read()

illumos/illumos-gate@57815f6b95a743697e148327725b7f568e75e6ea

Ticket: #3507

(cherry picked from commit 895ce82dcf35ca1b9ab74f9ec31a2cb8af19ac11)
MFV r258377: 4088 use after free in arc_release()

illumos/illumos-gate@ccc22e130479b5bd7c0002267fee1e0602d3f772

Ticket: #3508

(cherry picked from commit 2f8c61c931d711ebead15095345de089055e10bd)
MFC r246482 (rrs) + r246581:

This fixes a out-of-order problem with several of the newer
drivers. The basic problem was that the driver was pulling
the mbuf off the drbr ring and then when sending with xmit(),
encounting a full transmit ring. Thus the lower layer xmit()
function would return an error, and the drivers would then
append the data back on to the ring.  For TCP this is a
horrible scenario sure to bring on a fast-retransmit.

The fix is to use drbr_peek() to pull the data pointer but
not remove it from the ring. If it fails then we either call
the new drbr_putback or drbr_advance method. Advance moves
it forward (we do this sometimes when the xmit() function
frees the mbuf). When we succeed we always call advance.
The putback will always copy the mbuf back to the top of the
ring. Note that the putback *cannot* be used with a
drbr_dequeue() only with drbr_peek(). We most of the time,
in putback, would not need to copy it back since most likey
the mbuf is still the same, but sometimes xmit() functions
will change the mbuf via a pullup or other call. So the
optimial case for the single consumer is to always copy it
back.  If we ever do a multiple_consumer (for lagg?) we
will need a test and atomic in the put back possibly a
seperate putback_mc() in the ring buf.

Reviewed by:	jhb@freebsd.org, jlv@freebsd.org

(cherry picked from commit 42df175ae6ce79ca0cdc046901856ad3f6b51900)
MFC r257007,258140:

Update driver to version 10.0.664.0.

Many thanks to Emulex for their continued support of FreeBSD.

Submitted by:	Venkata Duvvuru <VenkatKumar.Duvvuru Emulex Com>

Ticket: #3305

(cherry picked from commit 488f318ff91977dbd4d13823dfcd79f264d926b9)