illumos gate

I think some combination of #10622, #10623, and #7119, is likely to make a shift in the devid for a ZFS pool device a non-event -- beyond a log message noting that the devid has changed.

That said, it would be good to confirm, during testing, a couple of cases:

• that a mirrored root pool is still bootable; unlike single-vdev root pools, changes in the devices path of disks in a complex pool (mirrors, raidz, etc) are not tolerated by the fix for #7119, but I believe devid-only changes should not impact boot under any circumstance
• that a non-boot pool (i.e., a second data pool other than the root pool) that is imported during boot via the cache file (i.e., it was not previously exported before reboot) survives across the change in devid as well

I think early boot ZFS pool things like that are probably the only things that end up using /etc/devices/devid_cache in any vaguely load-bearing fashion.

Testing: First I verified a system on a single-vdev root pool still boots with this change. As suggested by Josh, I also tested booting with a mirrored root pool, and with havin non-boot pool. Both cases worked as expected.

Note that after updating to #14686, going back to a previous BE only works if the previous BE has #14745. This is needed because the updated devid is stored in the vdev labels by ZFS, causing pool import problems on earlier versions.