Fix rare cksum errors after rebuild

Currently, after rebuild (aka sequential resilver), checksum
errors can be seen sometimes on the spare vdev or draid spare.
On my laptop, it happens from 2 to 4 times of running
redundancy_draid_spare1 test in a loop for 100 times.

It looks like there's a race in vdev_rebuild_thread() when the
rebuild of space map ranges is finished and we re-enable
allocations from the metaslab too soon: a new allocations may
happen from that metaslab before txg with the rebuilt ranges is
sync-ed, causing undesirable interference.

Solution: wait for the txg to be sync-ed before enabling metaslab.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Akash B <akash-b@hpe.com>
Signed-off-by: Andriy Tkachuk <atkachuk@wasabi.com>
Closes #18307
Closes #18319
Closes #18473

tests/zfs-tests/tests/functional/redundancy/redundancy.kshlib

@@ -360,12 +360,7 @@ function recover_bad_missing_devs
 #    expected state after a healing resilver of a healthy pool.
 #
 # 2. sequential - The pool is fully intact.  There should never be a
-#    checksum error, but the occasional checksum error does occur in
-#    practice.  Until the root cause is identified and resolved, tolerate
-#    a checksum error when scrubbing after a sequential resilver.
-#
-#    https://github.com/openzfs/zfs/issues/18307
-#    https://github.com/openzfs/zfs/issues/18319
+#    checksum error.
 #
 # 3. damaged - The pool was intentionally silently damaged.  Checksum
 #    errors are expected to be reported as the damaged blocks are
@@ -395,7 +390,7 @@ function verify_draid_pool
 			log_fail "Unexpected repair IO found for $pool ($cksum)"
 		fi
 	elif [[ "$replace_mode" = "sequential" ]]; then
-		if [[ $cksum -gt 3 ]]; then
+		if [[ $cksum -gt 0 ]]; then
 			log_must zpool status -v $pool
 			log_fail "Unexpected CKSUM errors found for $pool ($cksum)"
 		fi