fix: do not require CNI plugins for compose projects that avoid CNI

[ravi-arnan]

Fixes #4461

Problem

On a host with no CNI plugins installed, every nerdctl compose command fails, even when no
service in the project uses CNI networking:

services:
  probe:
    image: alpine
    network_mode: host
    command: echo OK

FATA[0000] failed to create default network: needs CNI plugin "bridge" to be installed in
CNI_PATH ("/opt/cni/bin"), see https://github.com/containernetworking/plugins/releases

Docker starts this project fine, and so does nerdctl run --net host on current main.

Cause

compose.New passed netutil.WithDefaultNetwork(...) to NewCNIEnv, which creates nerdctl's
default bridge network as a side effect of constructing the environment. That happens before any
service has been parsed, so it applies to every compose invocation regardless of what the services
actually ask for.

The default network is not needed there. The only consumer of that CNIEnv is NetworkExists, and
both call sites (up_network.go, down.go) invoke it exclusively with project-scoped names such as
myproject_default. External networks return before reaching it. Nothing in the compose path reads
the default bridge.

Services that genuinely use the default bridge are unaffected: compose shells out to nerdctl run,
and that path ensures the default network through cniNetworkManager when it is actually needed.

Fix

Drop WithDefaultNetwork from the CNIEnv built in compose.New. One-line change plus a comment
explaining why the eager creation is deliberately absent.

Verification

Built from this branch and compared against an unpatched build of the same commit, on Zorin OS 18
(kernel 6.17), containerd 2.3.3, runc 1.4.3. --cni-path and --cni-netconfpath were used to
simulate a host without plugins, so neither /opt/cni/bin nor /etc/cni/net.d was involved.

case	unpatched	patched
A. compose up, network_mode: host, empty CNI path	failed to create default network, service never ran	service ran
B. compose up, ordinary project on its _default bridge network, real plugins	service ran	service ran
C. compose up, network_mode: bridge, real plugins, empty netconf dir	n/a	service ran, and nerdctl-bridge.conflist was created on demand by the run path

Case C is the one the change could plausibly break, and it confirms the default network is still
created when a service actually asks for the bridge.

The TestComposeUp, TestComposeDown and TestComposeCreate selection was also run against both
builds from identical host state (leftover nerdctl bridges deleted between runs, since a stale
bridge holding 10.4.0.0/24 makes the next run fail the default network overlap check):

unpatched : 51 pass, 4 fail, 3 skip
patched   : 55 pass, 0 fail, 3 skip

Of the four failures on the unpatched build, one is the new regression test below, and the other
three are TestComposeCreatePull and two of its subtests failing on an IPv6 timeout reaching
ghcr.io. That one is unrelated to this change and passes on the unpatched build when the registry
is reachable. No test regressed.

For the plain run half of the issue report, both nerdctl run --net host and
nerdctl run --net none already succeed on unpatched main with no CNI plugins present, so that
half appears to have been fixed previously. Details are in the issue thread.

Test

TestComposeUpNetworkModeHostWithoutCNIPlugins runs compose up -d on a network_mode: host
project with --cni-path and --cni-netconfpath pointing at empty directories. It fails on
unpatched code with the error above and passes with the fix.

Note the test needs both flags. Pointing only --cni-path at an empty directory is not enough,
because a default network config left in the real netconf dir by an earlier test would satisfy
GetDefaultNetworkConfig and the creation attempt would never happen.

[haytok]

Totally LGTM, but I've left a comment.

[haytok]

nit:

Creating it eagerly made every compose command require a CNI plugin,
even for projects whose services all use network_mode: host or none.

This PR's commit message includes these comments, so they are redundant. It can be shortened, so WDYT?

[ravi-arnan]

Good catch, shortened to just the reason the call site needs. The rest only
described the history, which the commit message already carries. Amended and
force-pushed as b073d7c3.

On the 4 red jobs in this run: none of them are from this change, which is
comment-only. The previous head had a single red (in-host / windows), and that
one is still the same wall-clock assertion in TestRunRmTime.

The other three look like current repo-wide flakiness rather than anything here.
TestLoadQuiet is also red on #5131 and TestSave on #5136, both dependabot PRs
that touch no Go code, and #5136 additionally fails TestComposeRemove and
TestComposeRestart on EL / almalinux-8.

TestIPFSCompNoBuild is the one I looked at hardest, since it lives in
ipfs_compose_linux_test.go and this PR changes compose networking. It fails at
kubo.go:78 with context deadline exceeded polling the kubo HTTP API, and the
captured container log shows ipfs init had only just finished. That helper
starts the server with a plain nerdctl run -d -p ... and polls the published
host port, so it never goes through the compose path this PR touches. The
container started and got its address; the daemon just was not answering yet.

Happy to rebase or re-push if you want a clean run.

[haytok]

LGTM, Thanks

[AkihiroSuda]

Thanks