slirp4netns should honour the helper_binaries_dir config

[PhrozenByte]

Feature request description

Podman's slirp4netns implementation currently uses a custom logic to find the slirp4netns binary. See

podman/libpod/networking_slirp4netns.go

Lines 216 to 223 in 493aac6

	path := r.config.Engine.NetworkCmdPath
	if path == "" {
	var err error
	path, err = exec.LookPath("slirp4netns")
	if err != nil {
	return fmt.Errorf("could not find slirp4netns, the network namespace can't be configured: %w", err)
	}
	}

For some time now Podman chose to rely on r.config.FindHelperBinary() to find helper binaries. This method uses the helper_binaries_dir config in storage.conf (or the purposely undocumented CONTAINERS_HELPER_BINARY_DIR env variable for testing) and falls back to $PATH otherwise.

slirp4netns instead uses the custom single-purpose CLI option --network-cmd-path with a fallback to $PATH. slirp4netns doesn't honour the helper_binaries_dir config right now. Setting a path for slirp4netns is unnecessary hard because of this; due to the CLI option's generic name and a false documentation it even caused some confusion in the past (see #18560 and #18569 to fix it).

Suggest potential solution

Unify how Podman finds helper binaries: Podman should use r.config.FindHelperBinary() to find the slirp4netns binary and deprecate the --network-cmd-path CLI option.

For backwards compatibility reasons we must keep the --network-cmd-path CLI option for now (it should take precedence for now), but deprecate it by adding a note to the podman(1) manpage. We should then consider removing the option with Podman's next major release.

Have you considered any alternatives?

Previous discussion and reasoning for this approach see #18560

Additional context

Also see #18569 for the docs fixes

Cc: @Luap99

[rhatdan]

Interested in opening a PR?

[PhrozenByte]

Even though I'd love to learn Go, time's too limited for that, sorry 😒

[HirazawaUi]

I want work for this, if you don't mind, i will finish this issue.
/assign

[rhatdan]

SGTM