Fail invalid incremental recursive send gracefully

[ghost]

Motivation and Context

Issue #11121

zfs send -R -i snap1 pool/ds@snap1 is an invalid invocation of zfs send
because the incremental source and target snapshots are the same. We
have an error message for this condition, but we don't make it there
because of a failed assert while iterating through the dataset's
snapshots.

Description

Check for NULL to avoid the assert so we can make it to the error
message.

Test this form of invalid send invocation in rsend tests. Fix the
rsend_016_neg test while here: log_neg itself doesn't fail the test,
and writing to /dev/null is not supported on all Linux kernels.

How Has This Been Tested?

zfs send -R -i snap1 pool/ds@snap1 > /dev/null
Added the invalid invocation to an rsend 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.

[ghost]

• Rebased

[ghost]

• Rebased

[pcd1193182]

Out of curiosity, what Linux systems don't allow you to write to /dev/null? I thought that its behavior (discard all data written to it) was part of the POSIX spec.

[behlendorf]

@pcd1193182 for all the gory details you'll want to see this #11445 (comment) which links to the upstream kernel discussions. This started with the 5.10 kernel and basically boils down to our need to do the I/O from within the kernel using the kernel_read() and kernel_write(). Sadly since it's all happening kernel side we can't appeal to the POSIX spec. The core issue here remains and PR #11992 contains a WIP fix which it would be great to finally resolve.