Free network auto detection does not work if host has a 172.16.0.0/24 network on linux

[jeroost]

What's your CLI version?

1.8.1

Description & steps to reproduce

If you are on a public wifi with a linux machine (ubuntu), where the ip range allocated from wifi conflicts with the 172.16.0.0 range kurtosis is trying to use, it's conflict detection mechanism doesn't seem to work, probably because it can only detect conflicts inside the docker container, not outside.
Here:
container-engine-lib/lib/backend_impls/docker/docker_network_allocator/docker_network_allocator.go
Hence, routing of packets even simple dns requests fail.

There are cases where you cannot simply change the router's ip range, so it would be nice to be able to override the kurtosis ip range, like we can in docker itself from /etc/docker/daemon.json by setting e.g.

{
  "bip": "192.168.232.1/24",
  "default-address-pools": [
    {
      "base": "192.168.232.0/24",
      "size": 24
    }
  ]
}

Then interface docker0 has the right ip range, but interface br-xxx created by kurtosis has a conflicting 172.16.0.0 range (which, outside of docker also exists).
Note that this probably only applies for linux hosts where docker runs natively, so no VM is run. OSX users probably don't suffer form this as both OS's have a split view of the networks

Suggestion: take a free ip network from the docker configured range or allow overriding this in network_params section

Desired behavior

allocation of an ip in a non-conflicting range

What is the severity of this bug?

Painful; this is causing significant friction in my workflow.

What area of the product does this pertain to?

CLI: the Command Line Interface

[tedim52]

Hey @jeroost - thanks for making the issue! We've had similar requests before #2561. Completely agree this is smth that should be enabled. Is this blocking you from using Kurtosis right now, or do you have a workaround? Also, happy to work with you to make a contribution if you're open to it.