Need test cases for v2 loopback options

[mikebrow]

What is the problem you're trying to solve

PR #10238 needs an integration test .. #10238 (review)

Describe the solution you'd like

Need a test bucket for the config switch use_internal_loopback, test should run with the flag enabled and disabled.. Either a command on running a container or an exec request that checks status and/or uses localhost.. confirms the result.

Additional context

CNI loopback plugin is typically not configured by default in the list of cni plugins to run.. However, kubernetes networking requires loopback (lo) be set to on for localhost in all containers of a pod. For example, to support port forwarding scenarios, a program in a container can listen to localhost:port. Additionally some kubernetes networking providers enable loopback as a matter of course even if not configured.

Thus, it is currently expected the CRI container runtimes will always enable loopback at a minimum for kubernetes pod network namespaces to which every kubernetes scheduled container is attached. CRI container runtimes have two ways to enable loopback, by inserting loopback into list of CNI plugins attached to the pod network namespace, or by directly setting loopback to up. The new switch picks which of those methods are used to enable loopback.

[cameronldroberts]

Hey! I'd like to pick this up.

[fuweid]

Need a test bucket for the config switch use_internal_loopback, test should run with the flag enabled and disabled

I think we still need test case to check when containerd, which is running with use_internal_loopback=true, teardowns existing containers created by use_internal_loopback=false. As far as I know, the kernel will delete the loopback when net namespace is deleted.