Performance: Redundant chowning is being done in start.sh and ddev app.Start()

[rfay]

Expected Behavior

We don't want to do redundant time-consuming chowns, especially when they are chowning large directories, or when they require an extra Exec (container exec).

Actual Behavior

We're chowning multiple things with multiple operations.

• In ddev-webcontainer's start.sh, we sudo chown -R "$(id -u):$(id -g)" /mnt/ddev-global-cache/ /var/lib/php - this may be necessary in non-ddev context (where the image is being used outside ddev) but in general the ddev-global-cache is being done pre-emptively by app.Start(). (I did remove one instance of this so at least it's not being done twice now)
• In app.Start() we have several duplications, and when we duplicate things it means more container starts.
  • Every call to CopyIntoVolume() does its own chown, meaning an additional Exec() call.

    ddev/pkg/dockerutil/dockerutils.go

    Line 1260 in cf5bf15

    c := fmt.Sprintf("chown -R %s %s", uid, targetSubdirFullPath)

  • We chown /var/lib/mysql and /var/lib/postgresql separately, but they could be combined into one exec, one RunSimpleContainer(). The mounts would have to be constructed in advance and the bash command also.
  • The project_mutagen volume is also separately chowned, and this may be time-consuming if it's large

Note that we may not even always have to chown, if it's already been done. For example, the project_mutagen volume really only needs to be done when the volume is created. But we could have a check in some of these places where we see if the ownership is already correct.

Steps To Reproduce

DDEV_DEBUG=true ddev start - look for the chowns.
ddev logs - look for the chowns

[rfay]

In #4944 I attempted to fix the double-chown in start.sh, but it caused unknown problems with a few tests, so I removed that part and just fixed the too-late-mutagen.yml generation problem. So the redundant chowning is all still there for us.

[rfay]

This is relatively hard to solve and relatively low impact. One part is solved in #5686

I think I'm willing to ignore this, closing for now.