Defer async destroys on pool import

We've observed a number of cases when pool import stuck for many
minutes due to large async destroy trying to load DDT or BRT from
HDD pool.  While proper destroy dosage is a separate problem,
lets give import process a chance to complete before that at all.
It may be not enough if there is a lot of ZIL to replay, but that
is harder to cover, since those are in separate syscalls.

Code investigation shown that we already have this mechanism used
for scrub/resilver, so this patch converts SCAN_IMPORT_WAIT_TXGS
into a tunable and applies it to async destroys also.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <alexander.motin@TrueNAS.com>
Closes #18033

man/man4/zfs.4

@@ -1767,6 +1767,16 @@ Blocks that go to the special vdevs are still written indirectly, as with
 .Sy logbias Ns = Ns Sy throughput .
 This parameter is ignored if an SLOG is present.
 .
+.It Sy zfs_import_defer_txgs Ns = Ns Sy 5 Pq uint
+Number of transaction groups to wait after pool import before starting
+background work such as asynchronous block freeing
+.Pq from snapshots, clones, and deduplication
+and scrub or resilver operations.
+This allows the pool import and filesystem mounting to complete more quickly
+without interference from background activities.
+The default value of 5 transaction groups typically provides sufficient time
+for import and mount operations to complete on most systems.
+.
 .It Sy zfs_initialize_value Ns = Ns Sy 16045690984833335022 Po 0xDEADBEEFDEADBEEE Pc Pq u64
 Pattern written to vdev free space by
 .Xr zpool-initialize 8 .