I think this is similar to, but supersedes https://github.com/openzfs/openzfs/pull/648/, is that right?
There were a few follow on commits which George Wilson or Tom Caputi can point you at, including a8b2e30685c9214ccfd0181977540e080340df4e "Support re-prioritizing asynchronous prefetches"

I know you didn't write this code so I only concentrated on looking for possible bugs or problems. Overall this looks good. I assume this was already reviewed by people who are more knowledgeable about zfs than me. Here are the issues I noticed.
usr/src/uts/common/fs/zfs/arc.c

348-349 This comment seems wrong now

5069 At first I thought this should still be wrapped in VERIFY0, but after

     looking at the next change, I think we're missing the assignment of

     the return to 'rc'.
usr/src/uts/common/fs/zfs/dbuf.c

2445 Why was this block added? It looks redundant with the existing block

     at 2406.

usr/src/uts/common/fs/zfs/dsl_scan.c

99 s/limitted/limited/

137 and 160 either change to boolean or use 0

159 this tunable seems worthy of an explanatory comment

384 I'm not sure why the fill_weight code is duplicated here from scan_init.

1757 Unless I'm misreading the code, it appears that we'll leak bp_toread if 

     dsl_scan_recurse returns an error.

3857 I don't see how the rest of the code in this function will block the 

     caller. Is something missing here?
usr/src/uts/common/fs/zfs/range_tree.c

210 This function seems kind of problematic. If rtop_remove is set but

    rtop_add is NULL, we lose the entry. It seems like it would be better

    to do the checks up front before we remove/adjust/add, although based

    on how this is used, maybe it should just assert the ops? I don't see

    any of these with only one op and not the other. I'm not sure why the

    extra checks were added for the individual ops throughout the code.
usr/src/uts/common/fs/zfs/sys/dsl_scan.h

136 Trailing whilespace. cstyle should have caught this.

I went back through my old review comments and cross checked them with the latest ZoL code. These are my comments that I still think we need to address:
usr/src/uts/common/fs/zfs/arc.c

5069 assign return value to 'rc'
usr/src/uts/common/fs/zfs/dbuf.c

2445 Why was this block added? It looks redundant with the existing block at 2406 and doesn't exist in ZoL.
usr/src/uts/common/fs/zfs/dsl_scan.c

99 s/limitted/limited/ this is spelled correctly in ZoL.

384 I'm not sure why the fill_weight code is duplicated here from scan_init, which matches ZoL. This function doesn't exists in ZoL. We would also need to remove call from spa_init.

1757 We'll leak bp_toread if dsl_scan_recurse returns an error. In ZoL, code does goto out.
usr/src/uts/common/fs/zfs/sys/dsl_scan.h

136 Trailing whilespace, doesn't exist in ZoL.

you'll also want the fix for https://github.com/zfsonlinux/zfs/pull/8453 (once finalized).

I went back through the diffs that have changed since the last last time I reviewed this, and it looks good to me, as long as the separate "Multiple DVA Scrubbing Fix" which you ported from ZoL is also included in the same integration.

Thanks for updating the tests, sorry I missed that earlier.

usr/src/uts/common/fs/zfs/dsl_scan.c (Diff revision 8)

It seems to me like it would be more correct if these were hrtime_t. I see scn_sync_start_time is a uint64_t, so maybe this isn't such a big deal.

1. 

   Toomas Soome April 19, 2019, 1:12 a.m.

   I think, we should be correct there, the zol gethrtime() is also returning hrtime_t.

2. 

   Jerry Jelinek April 19, 2019, 5:16 p.m.

   I'm confused about this change. It seems like the ZoL patch removed the elapsed_nanosecs variable altogether and you didn't change the type on the following line where curr_time_ns is still a uint64_t. Am I misreading this somehow?

3. 

   Toomas Soome April 19, 2019, 5:23 p.m.

   yep, it is my mistake there.

usr/src/uts/common/fs/zfs/dsl_scan.c (Diff revision 8)

IIUC, Linux has much more stringent stack requirements than illumos. I would vote to keep this in, but I know we're trying to minimize our diff from ZoL. The ZoL issue states that this saves up to 390 bytes with a recursion depth of around 13.
Also, if it matters, it doesn't look like this was added to ZoL as part of the sequential scan/scrub change.

1. 

   Toomas Soome April 19, 2019, 1:12 a.m.

   yes, I am aware of linux limit, also we can always use dtrace:)

Thanks for fixing that up, this looks good to me now.