ZTS: use openssl for md5digest and sha256digest

[mcmilk]

Motivation and Context

On larger files this should improve the speed for the testings a bit. It also
simplifies things a bit.

Sample values of my system:

[mcmilk@xz]$ time dd if=/dev/zero bs=128k count=1k | sha256sum
254bcc3fc4f27172636df4bf32de9f107f620d559b20d760197e452b97453917  -
real    0m1,050s
user    0m0,985s
sys     0m0,153s

[mcmilk@xz]$ time dd if=/dev/zero bs=128k count=1k | openssl sha256 -r
254bcc3fc4f27172636df4bf32de9f107f620d559b20d760197e452b97453917 *stdin
real    0m0,254s
user    0m0,206s
sys     0m0,160s

I think the cli_root/zdb/zdb_backup.ksh test runs also on FreeBSD and depends on md5sum,
which is not provided per default on FreeBSD. I needed to include the sysutils/coreutils
package for the QEMU patchset - I think.
This could be reverted, when this pull request gets upstream.

Signed-off-by: Tino Reichardt milky-zfs@mcmilk.de

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[amotin]

I wonder if openssl might have a longer startup time and/or bigger memory footprint, which might cost more than save for small amounts of data.

[mcmilk]

I wonder if openssl might have a longer startup time and/or bigger memory footprint, which might cost more than save for small amounts of data.

You are right, thats the reason I have not replaced e.g. the recursive_cksum of functional/rsend/*.
This needs testing a bit - I will provide some timings for this.