jail: fix backfilling the "name" for jid-named jails

[kevans]

Summary

Using the cfparam variant of add_param() will actually copy the name and
flags from the passed-in param, which I hadn't considered. We actually
want the name/flags from the "name" param so that we can do variable
expansion against it right after that -- otherwise it cannot be found,
since variable expansion actually searches by name.

While we're here, jls -e was the intermediate name for jls -c that
never saw the light of the day. Fix our existence test.

Fixes: 02944d8c49 ("jail: consistently populate the KP_JID [...]")

[kevans]

Gentle ping; this is the result of a discussion on the mailing list about how jid { host.hostname = "${name}" } doesn't work; it almost works in FreeBSD 15.0, but we end up not resolving the "name" variable because I had inadvertently copied the name of the jid parameter into this value for the KP_NAME due to how add_param() works when passed a cfparam instead of a string value.

[crest_freebsd_rlwinm.de]

The current behavior is that if the jail block opens with a number instead of a string the number is bound to the jid parameter and the name parameter is left unbound. This means there're probably existing configurations in someone's production that use this way to set the jid and assign the name inside the jail block e.g. 42 { name = "my_jail"; } instead of my_jail { jid = 42; }. Changing this long standing, but underdocumented behaviour would break those jail configurations. :-/

[kevans]

In D51831#1186084, @crest_freebsd_rlwinm.de wrote:

The current behavior is that if the jail block opens with a number instead of a string the number is bound to the jid parameter and the name parameter is left unbound. This means there're probably existing configurations in someone's production that use this way to set the jid and assign the name inside the jail block e.g. 42 { name = "my_jail"; } instead of my_jail { jid = 42; }. Changing this long standing, but underdocumented behaviour would break those jail configurations. :-/

That's why this is positioned where it is, so that it doesn't override an existing name. You'll note the test line 212 is that exact scenario, but I guess it doesn't confirm explicitly that the name did not get overridden.

[jamie]

Yep, tried it out and it looks good now.