zfs: wolfZFS port for OpenZFS 2.4.2 (FIPS fixes; supersedes #341)

[ColtonWilley]

Updates the wolfZFS port to OpenZFS 2.4.2 (tag zfs-2.4.2) and folds in the FIPS fixes. Supersedes #341 (which carried only the -287 unlock) — that PR can be closed.

Changes vs the cd06f79e2 port

• Rebased to zfs-2.4.2 — applies with 0 fuzz to both upstream zfs-2.4.2 and Proxmox 2.4.2-pve1.
• module/zfs/hkdf.c: PRIVATE_KEY_UNLOCK bracket fixes FIPS_PRIVATE_KEY_LOCKED_E (-287) on encrypted dataset creation under wolfCrypt FIPS (this was zfs: fix FIPS_PRIVATE_KEY_LOCKED_E (-287) on encrypted dataset creation under wolfCrypt FIPS #341).
• In-kernel RNG keygen (wc_InitRng / wc_RNG_GenerateBlock) for the zfs_ioctl_os.c control sites and the zio_crypt.c per-block IV hot path.
• Userspace key-derivation switched to provider-native EVP_KDF "PBKDF2" + RAND_bytes salt, so it routes through an OpenSSL 3.x provider (e.g. wolfProvider).
• MODULE_IMPORT_NS("WOLFSSL") quoted for kernel >= 6.13.

Validation

Built and exercised on Proxmox VE 9.2 (zfs-2.4.2-pve1, kernel 7.0.12-1-pve):

• Patch applies with 0 fuzz to both upstream zfs-2.4.2 and Proxmox 2.4.2-pve1.
• Kernel module (--with-config=kernel) builds: depends: spl,libwolfssl, 28 wc_ imports, 0 _fips symbols.
• Encrypted dataset (aes-256-gcm) round-trips through wolfCrypt and survives reboot.

Patch stat: 41 files changed, 1002 insertions(+), 28613 deletions(-).

[ColtonWilley]

Updated to fold in a small test-wiring fix the OpenZFS test suite exposed: the userspace ICP checksum test programs sha2_test/blake3_test link libicp.la directly, so they need -lwolfssl (otherwise undefined reference to wc_Sha256Final). Appended to their LDADD in tests/zfs-tests/cmd/Makefile.am.

Full validation on this patch (built from wolfSSL master for --enable-wolfzfs):

• run_crypto: 2/2 — icp_aes_ccm 552/552, icp_aes_gcm 316/316 (both [wolfcrypt]-tagged, i.e. KATs route through wolfCrypt).
• run_sanity: 822 PASS / 6 FAIL (99.3%); the 6 failures are a strict subset of the known vanilla-ZFS environmental failures — zero wolfCrypt-routing regressions. Encryption-exercising tests (zfs_send/receive_from_encrypted/rsend, encrypted create) all pass.
• Applies with 0 fuzz to both upstream zfs-2.4.2 and Proxmox zfs-2.4.2-pve1; kernel module + encrypted-dataset round-trips validated on Proxmox VE 9.2 (kernel 7.0.12-1-pve).

[philljj]

This is cool and tests nicely on Debian 13 with a tiny modification.

Two suggestions:

1. We break patches/ into distros, like: patches/debian13/, patches/proxmox_ve_9.2/. I think the original debian 13 trixie POC is a generally applicable reference that we should keep.

2. It seems there is still userspace -lwolfssl linking even with this PR:

.libs/libzpool.so
        linux-vdso.so.1 (0x00007f04383d5000)
...
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f0438397000) 
        libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f0438337000)
        libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f0437dbb000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0437d9b000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0437cab000)
        libwolfssl.so.45 => /usr/local/lib/libwolfssl.so.45 (0x00007f0437a00000)

If userspace -lwolfssl linking is unavoidable, we could patch the userspace part of OpenZFS to use wolfssl directly, and not use compat layer or provider interface.