MFC r356279: libbe(3): promote dependent clones when destroying a BE

When removing a boot environment iterate over the dependents and process the
snapshots by grabbing any clones. Promote the clones we found and then
remove the target environment.

This fixes the ability to destroy a boot environment when it has been used
to spawn one or more other boot environments.

PR: 242592

MFC r349380, r349383, r349455: bectl(8)/libbe(3) fixes

r349380:
libbe(3): mount: the BE dataset is mounted at /

Other parts of libbe(3) were fairly strict on the mountpoint property of the
BE dataset, and be_mount was not much better. It was improved in r347027 to
allow mountpoint=none for depth==0, but this bit was still sensitive to
mountpoint != / and mountpoint != none. Given that other parts of libbe(3)
no longer restrict the mountpoint property here, and the rest of the base
system is generally OK and will assume that a BE is mounted at /, let's do
the same.

r349383:
libbe(3): restructure be_mount, skip canmount check for BE dataset

Further cleanup after r349380; loader and kernel will both ignore canmount
on the root dataset as well, so we should not be so strict about it when
mounting it. be_mount is restructured to make it more clear that depth==0 is
special, and to not try fetching these properties that we won't care about.

r349455:
bectl(8): create non-recursive boot environments

bectl advertises that it has the ability to create recursive and
non-recursive boot environments. This patch implements that functionality
using the be_create_depth API provided by libbe. With this patch, bectl now
works as bectl(8) describes in regards to creating recursive/non-recursive
boot environments.

MFC r348215, r348219: fix bectl(8) jail w/ numeric BE names

r348215:
jail_getid(3): validate jid string input

Currently, if jail_getid(3) is passed in a numeric string, it assumes that
this is a jid string and passes it back converted to an int without checking
that it's a valid/existing jid. This breaks consumers that might use
jail_getid(3) to see if it can trivially grab a jid from a name if that name
happens to be numeric but not actually the name/jid of the jail. Instead of
returning -1 for the jail not existing, it'll return the int version of the
input and the consumer will not fallback to trying other methods.

Pass the numeric input to jail_get(2) as the jid for validation, rather than
the name. This works well- the kernel enforces that jid=name if name is
numeric, so doing the safe thing and checking numeric input as a jid will
still DTRT based on the description of jail_getid.

r348219:
bectl(8): Add a test for jail/unjail of numeric BE names

Fixed by r348215, bectl ujail first attempts the trivial fetch of a jid by
passing the first argument to 'ujail' to jail_getid(3) in case a jid/name
have been passed in instead of a BE name. For numerically named BEs, this
was doing the wrong thing: instead of failing to locate the jid specified
and falling back to mountpath search, jail_getid(3) would return the input
as-is.

While here, I've fixed bectl_jail_cleanup which still used a hard-coded pool
name that was overlooked w.r.t. other work that was in-flight around the
same time.

Approved by: re (marius)

MFC bectl(8)/libbe(3): r337663-337664,337667,337697-337699,337800,337805,
337915-337918,337921,337924,337947,337993-337995,338221-338222,338303,
338417,339047,339972,339994,340334,340507-340508,340592-340594,
340635-340636,340722-340723,340974,342466,342849,342903,342911,343335,
343543,343977,343993-343994,344034,344067,344084,345302,345769,
345845-345846,345848,346082

There are simply too many small changes to enumerate; in summary:

bectl(8)/libbe(3) has been introduced from current state in -CURRENT and
added to the stable/11 rescue build. bectl(8) is a tool for managing ZFS
boot environments, largely inspired by beadm. It includes features such as
being able to jail a boot environment or easily mount it for modification.

Relnotes: probably

bectl(8): Add some regression tests

These tests operate on a file-backed zpool that gets created in the kyua
temp dir. root and ZFS support are both required for these tests. Current
tests cover create, destroy, export/import, jail, list (kind of), mount,
rename, and jail.

List tests should later be extended to cover formatting and the different
list flags, but for now only covers basic "are create/destroy actually
reflected properly"

MFC after: 3 days