fix: internal project network with duplicate check, revert for #5305

[stasadev]

The Issue

• fix: make project network external, fixes #5193 #5305
• fix: ensure no duplicates for docker networks, fixes #5193 #5508
• Multiple ambiguous docker networks created #5193

After switch to external project networks in #5305, there were issues with compatibility between different DDEV version, which made downgrade not smooth.

The last issue with downgrade from HEAD to v1.22.4:

$ ddev start
...
Building project images... 
Project images built in 3s. 
time="2023-11-07T08:29:14-07:00" level=warning msg="a network with name ddev-d10_default exists but was not created by compose.\nSet `external: true` to use an existing network" 
network ddev-d10_default was found but has incorrect label com.docker.compose.network set to "" 
Failed to start d10: composeCmd failed to run 'COMPOSE_PROJECT_NAME=ddev-d10 docker-compose -f /Users/rfay/workspace/d10/.ddev/.ddev-docker-compose-full.yaml up -d', action='[]', err='exit status 1', stdout='', stderr='time="2023-11-07T08:29:14-07:00" level=warning msg="a network with name ddev-d10_default exists but was not created by compose.\nSet `external: true` to use an existing network"
network ddev-d10_default was found but has incorrect label com.docker.compose.network set to ""'

How This PR Solves The Issue

Move back to internal project networks, and create them before docker-compose up to ensure no duplicates.

I've refactored the code to make it clearer what's going on. In the previous PR #5305, it was unclear where and why the project network was created.

Manual Testing Instructions

Use DDEV as usual.

Automated Testing Overview

Related Issue Link(s)

Release/Deployment Notes

[github-actions]

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-linux-amd64.zip
• ddev-linux-arm64.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-windows-amd64-installer.zip

See Testing a PR

[stasadev]

The only difference between a network created with docker-compose up and from DDEV is this set of labels:

$ docker inspect ddev-your-project_default
...
        "Labels": {
            "com.docker.compose.network": "default",
            "com.docker.compose.project": "ddev-your-project",
            "com.docker.compose.version": "2.23.0"
        }
...

And when you have a network with these labels created programmatically, docker-compose up runs as usual.

I see this as a win because with this approach we can have a project network at an early stage, I guess there might be some kind of race condition that creates duplicates for the networks in docker-compose up.

[stasadev]

This PR is easy to revert, you only need to remove this function call and the function itself.

[stasadev]

This is a fix for a bug that I introduced in #5508

When you run ddev stop or ddev poweroff several times in a row, Network <name> removed is shown each time, even if there is no such network.

[stasadev]

There is only refactoring.

[stasadev]

There are some testing errors, I restarted them and they failed again.
Don't really know if these failures are related to this PR.

[rfay]

The colima failure was Colima regression in v0.6.0, should be fixed in v0.6.2, abiosoft/colima#856

The wsl failure looks like just internet problems or upstream problems.

I'll restart both again.

[rfay]

If you're good with it I'm good with it. Thanks again for pursuing this!

[stasadev]

Yeah, let's pull it in. Looks pretty good considering we have version control over docker-compose.
So, if something changes with the docker-compose labels, we can handle it easily.