ZTS: Use /dev/urandom instead of /dev/random

[tonyhutter]

Motivation and Context

Use /dev/urandom so we never have to wait on entropy.

Description

Psudorandom numbers are fine for ZTS. Use /dev/urandom since it's faster than /dev/random.

How Has This Been Tested?

buildbot will test

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.

[rincebrain]

On 5.6+, this will do nothing, because they're identical once the CSPRNG is initialized, and ZTS will probably never be running before that's true.

So unless you're hoping to speed up the CentOS 8 and Ubuntu 20.04 runs specifically, this seems pretty academic.

[tonyhutter]

@rincebrain to tell you the truth, this PR started as a low-effort attempt to fix the recent block_cloning_rlimit_fsize.ksh failures on Centos 8:

https://build.openzfs.org/builders/CentOS%208%20x86_64%20%28TEST%29/builds/3643/steps/shell_4/logs/tests
https://build.openzfs.org/builders/CentOS%208%20x86_64%20%28TEST%29/builds/3638/steps/shell_4/logs/tests
https://build.openzfs.org/builders/CentOS%208%20x86_64%20%28TEST%29/builds/3637/steps/shell_4/logs/tests

I was looking at block_cloning_rlimit_fsize.ksh and noticed the dd if=/dev/random of=/$TESTPOOL/file1 bs=1 count=1000 in there and thought it may be hanging while waiting for entropy. I wasn't convinced that was the case but I figured it was worth a shot. I saw some other test cases where we use /dev/random, and thus this PR was born.

It does look like this PR passed block_cloning_rlimit_fsize.ksh which is encouraging: https://build.openzfs.org/builders/CentOS%208%20x86_64%20%28TEST%29/builds/3642/steps/shell_4/logs/tests