zfs(openzfs): enable a runtime ZFS data pool on a non-ZFS-root image (follow-on to #1423)

[gburd]

Follow-on to #1423 (in-kernel OpenZFS). These six changes let an OSv image
whose root filesystem is not ZFS (for example fs=ramfs) bring up an OpenZFS
data pool on a local disk at runtime and serve an application from it. Each
is small and independent; together they close the gaps that prevented
--preload-zfs-library + a runtime zpool create from working, plus one ZIL
latency bug.

1. loader: init the ZFS control device when preloading libsolaris
--preload-zfs-library only loaded libsolaris.so; it did not create the
/dev/zfs control device, so zpool/zfs could not talk to the kernel
(/dev/zfs not found). Call zfsdev_init() on the preload path as the
fs=zfs root-mount path already does.

2. loader: load ZFS libsolaris with RTLD_GLOBAL
The ZFS userspace tools link only against libzfs.so and libc and resolve
their nvpair/nvlist symbols against libsolaris.so at runtime. Loading it
RTLD_LOCAL left those out of the global scope, so a later dlopen of the
tools reported dozens of missing symbols and could not create the control
device. Load with RTLD_GLOBAL.

3. loader: create /etc/mnttab when preloading ZFS
The tools consult /etc/mnttab; on a non-ZFS root nothing creates it. Create
an empty one on the preload path (mirrors the in-tree ZFS bench harness).

4. loader: preload the ZFS library before the root-mount block
dlopen of /usr/lib/fs/libsolaris.so from a bootfs ramfs root fails once the
root-mount block has run its unmount/pivot sequence, which is why the fs=zfs
path (which loads libsolaris before the pivot) worked while a later preload did
not. Run the preload before the root-mount block.

5. modules/open_zfs: carry the libsolaris.so manifest entry on the provider
The libsolaris.so manifest entry lived on the zfs placeholder module, but
the placeholder is replaced by its provider (open_zfs) during module
resolution, so the entry was dropped and libsolaris.so never landed in
usr.manifest. For a bootfs-populated fs=ramfs image this silently omitted
it. Generate the entry on the provider module.

6. zfs(openzfs): nanosecond-precise cv_timedwait_hires so ZIL commits coalesce
cv_timedwait_hires rounded its nanosecond deadline to ddi_get_lbolt ticks;
at hz=1000 a tick is 1ms, so the ZIL commit-batch window (a few hundred
microseconds) rounded to zero and concurrent fsyncs never coalesced into one
log write plus one device cache flush. Wait the true remaining nanoseconds via
the OSv condvar chrono wait, honoring the absolute vs relative flag.

Testing

Built (conf_zfs=openzfs) and booted. With these applied, a fs=ramfs OSv
image with --preload-zfs-library creates an OpenZFS pool on a local disk at
runtime, and stock PostgreSQL serves with its data directory on ZFS, both under
QEMU and native on the instance.

[gburd]

Follow-up correctness fix pushed (25bde6b): the absolute-deadline branch of cv_timedwait_hires was using the wrong clock base.

gethrtime() on OSv is clock_gettime(CLOCK_UPTIME), and CLOCK_UPTIME is #defined to CLOCK_REALTIME (see bsd/sys/cddl/compat/opensolaris/sys/time.h), so an absolute gethrtime() deadline is a wall-clock nanosecond value (order 1.7e18 ns). The previous code subtracted uptime-now (order 1e11 ns at boot) from that wall-clock deadline, yielding a delay of order 1.7e18 ns, roughly fifty years. The ZIL commit-batch timeout timer was armed effectively forever and never fired. A backend that also missed its log-write-completion signal then waited on the condition variable permanently and stalled every later committer behind it, wedging synchronous-commit writes under concurrency.

The fix subtracts wall-clock now to match gethrtime()'s clock base. The relative branch already used the wall clock; only the absolute branch was wrong. Comments describing the deadline as uptime are corrected.

Diagnosed by reading a wedged guest's stuck backend directly: it was correctly enqueued and unwoken on a ZFS condition variable with an armed timer whose parked deadline was a wall-clock epoch value interpreted as uptime, so the timeout never arrived.