support NVMe Deallocate

[ahrens]

This implements #990. It makes propolis advertise support for the "Dataset Management" NVMe command. It uses ioctl(DKIOCFREE) to pass these requests through to local disks (FileBackend). The requests are ignored on distributed disks (Crucible).

Note that our devices are NVME 1.0e, which specifies that the disk "may" deallocate all provided ranges, and "shall return all zeros, all ones, or the last data written to the associated LBA". The 1.0e spec has no mechanism for telling the guest which of these semantics is actually happening. Future work may include migrating to NVME 1.1 or later, which can use the DRB (Deallocation Read Behavior) field to tell the guest whether the blocks are actually zeroed or not.

This requires the changes for https://github.com/oxidecomputer/stlouis/issues/940 which are under review here.

A few details to be aware of or provide input on:

1. I am always advertising support for the Dataset Management command (with a bit in the oncs field). I think this is OK since there is no live migration currently (even if the VM has no local disks). So each time a VM boots, it will be on a specific version of Propolis which either advertises Dataset Management, or not.
2. block::Operation::Discard now means to discard multiple ranges from the client-provided list, not just one range. probes::block_begin_discard used to take an offset and length, but I have changed it to take the number of ranges instead. Is this OK? Are there consumers that need to change? We could fire a probe for each range, but then there would be multiple “begin” probes for one devqid, which could be confusing because begin/complete probes would not match up. Similar for probes::nvme_discard_enqueue.
3. In VirtualDiskStats, should we add stats for Discard? How do we monitor these? Would we need to add support in consumers?

[ahrens]

testing: installed the ZFS changes and this Propolis on mb-1. In the linux guest VM, created a zpool on a local disk and used zpool trim and zpool set auotrim=on to cause it to issue Deallocate commands. I used dtrace to observe that vdev_disk_issue_trim() is called on the underlying physical disk.

[iximeow]

nice, this will be nice to have, thanks for working on this. hopefully none of the comments are too surprising!

[iximeow]

FWIW I'm a solid +1 on this now, thanks! if you're going to add a test about DatasetManagementCmd with bogus prp1/prp2 then I'll be happy to take a look at that here too. if not (or you have surprise issues), this is a nice improvement as-is.

[rmustacc]

Thanks for the work on this.