fix for 3740 changed behavior of zfs destroy/hold/release ioctl
In the fix for #3740 the behavior of the ZFS snapshot destruction, hold, and release IOCTLs from "ignore missing snapshots when determining the returned error (but returning ENOENT in the errlist for each missing snapshot)" to "ignore missing snapshots when determining the returned error, unless all snapshots are missing in which case ENOENT is returned". While the new behavior more closely matches what the 'zfs' command does it is not ideal for programmatic consumers and breaks existing consumers.
The goal of the old behavior was to avoid races with 'destroy' (a common case for any program that does not have a way to stop snapshots from being destroyed while it is building the list of snapshots to send in the IOCTL for example 'zfs destroy/hold/release -r'). Any consumer that cares about missing snapshots could check the returned 'errlist' for ENOENT. With the new code consumers that care about missing snapshots still need to check 'errlist' because a return code of 0 only means that at least one of the snapshots existed, while consumers that don't care about missing snapshots now need to explicitly ignore ENOENT.
The 'zfs' command line does want the "error if none of the snapshots exists" behavior, but implements it differently.