fix(devcontainer): chown regression for make codegen

[Joibel]

#13348 removed a recursive flag from chown. I believe was done because this is slow on macintosh filesystems.

This breaks codegen with

fatal: could not create leading directories of '/home/vscode/go/src/github.com/gogo/protobuf': Permission denied

This is a smaller recursive chown which fixes the issue for me.

[qingfeng777]

It worked in my development environment.

[agilgur5]

It worked in my development environment.

The fix works, to clarify

[agilgur5]

This breaks codegen with

Dang, can confirm it does this in my devcontainer too. This might be due to similar reasons as #13145 that codegen didn't run.

Thank you both for catching this!

I believe was done because this is slow on macintosh filesystems.

Atrociously slow -- many minutes, I don't think I've ever once waited till the end, I have no idea how long it could take total. Since it worked fine even with me cancelling part-way, something about it isn't entirely necessary.
Although I'm not sure it's Mac FS specific per se, since the command is running inside the container on files that only exist in the container, and has no affect on the host FS. But it clearly doesn't happen everywhere, so idk what the root cause is.

From a quick trace, it does seem like a lot of time is spent on the .git directory; even if the error is silenced from #13111, it still recurses through it. I don't think we need to recurse through, especially not the entire source dir, we just need to figure out which directories need to have chown applied

[Joibel]

I believe was done because this is slow on macintosh filesystems.

Atrociously slow -- many minutes, I don't think I've ever once waited till the end, I have no idea how long it could take total. Since it worked fine even with me cancelling part-way, something about it isn't entirely necessary. Although I'm not sure it's Mac FS specific per se, since the command is running inside the container on files that only exist in the container, and has no affect on the host FS. But it clearly doesn't happen everywhere, so idk what the root cause is.

I'm not saying it's mac specific, but either APFS or the docker desktop virtualisation through to APFS is causing slowdown. The writes are happening in the docker overlay, but they presumably have to thunk through to understand the underlying files.

On Linux with the source files on ext4 and using btrfs as the docker storage driver this takes less than 2 seconds. When I wrote this chown originally I wasn't using btrfs, just overlay2, and it was a much slower computer, and it was still unnoticable as a part of startup.

[agilgur5]

The writes are happening in the docker overlay, but they presumably have to thunk through to understand the underlying files.

Presumably, although something feels off that other FS commands aren't similarly slow

I'm curious if someone else has the same issue on Mac? Did Adrien have it too?

Although if these 3 directories are enough, then we won't need to worry about it either way (although it is possible another FS-type issue could crop up again with the devcontainer in the future)

From a quick trace, it does seem like a lot of time is spent on the .git directory

The other outlier is that my .git directory is probably larger than most, since I have lots of branches, stashes, a big reflog, a few remotes to other contributors etc.
Potentially an FS inefficiency combined with that causes the slowdown