Channel programs: add zfs.sync.clone()

[robn]

Motivation and Context

A popular request on the OpenZFS Production Users call is the ability for channel programs to create clones. I was catching up on this week's call at lunch today and heard it again and, in need of a palate cleanser after far too much correctness work this week, I took a swing at it. A pleasant diversion!

Description

Adds zfs.sync.clone(snapshot, newdataset). Since clone is already implemented with a standard check/sync pair of functions, it's all really just wiring.

How Has This Been Tested?

New tests included to test the new call, based on the existing zfs.sync.snapshot() tests. Since I've renamed and moved things around, I ran the zfs_clone tests also. All is well!

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)
• Quality assurance (non-breaking change which makes the code more robust against bugs)
• 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.

[Crest]

Would creating new (empty) filesystems be just as easy? How would mounting the filesystems be handled? Would the channel program be expected to return the list of filesystems to be mounted?

[Crest]

Would it be possible to also set (non-inheritable) properties on the clone e.g. canmount=noauto?

[robn]

Would creating new (empty) filesystems be just as easy?

@Crest Quick glance says a bit harder, but maybe not very hard, at least for the simple cases.

How would mounting the filesystems be handled? Would the channel program be expected to return the list of filesystems to be mounted?

Unclear to me. I would expect the program itself wouldn't need to do anything; there's already a list of "datasets that were created" on the channel program context that are considered for follow-up work after the fact; this is how device nodes for new zvols are created (this functionality already existed to support zvol snapshots with snapdev=visible).

The tricky part for mounts is that we don't currently have a clean, cross-platform way to set up a mount from inside the kernel. Most of mounting is handled entirely by zfs mount, and on Linux we don't even do snapdir mounts inside the kernel - we create a new userspace process and execute mount.

It would take some actual hard thinking to work out what the right thing to do here is. I won't write it all out, but I have a bunch of questions about permissions, and channel program context, and the calling program, and containers/jails, etc.

Would it be possible to also set (non-inheritable) properties on the clone e.g. canmount=noauto?

I think that's not hard to do. When user properties were added in #9950 it even said that its limited to those because that's all they needed. There might be some that need a little more thought, but constraints like "non-inheritable" and perhaps "no side effects" should be an easy starting point.

These are all good avenues for future exploration, not for this PR. Keep banging on about it, and I'll probably get there ;)