Added a devcontainer setup for any host OS that has a container manager

[Clearmist]

Description

I have added a modern Dev Containers setup to much more quickly get new contributors into a development environment.

Check out .devcontainer/README.md for details.

Summary (all done automatically)

• Downloads and runs the required PostgreSQL and Redis containers.
• Builds a dev container to host the source code.
• Populates the database then runs all migrations.
• Creates a default dev:dev superuser.
• Starts the webserver on localhost:8000.

Checklist

• ✅ Tests pass locally. Coverage is at 68%. Given that I made no code changes this coverage value is what is expected.
• ✅ Linted. No code changes made.
• [N/A] New/changed user-facing strings in templates, forms, and views are
  wrapped for translation in templates.
• [N/A] Migrations included.

[Clearmist]

I saw your recent commit about podman being unreliable in VSCode. I'm happy you were able to test and see some issues. My own setup is VSCode and podman on Linux and I haven't had any issues getting Dev Containers to work.

[bpepple]

So, it looks alright for the most part tho I made some changes for a few items:

1. Load the series_type fixture on a fresh database.
2. Drop --noreload from the auto-started dev server so edits are picked up without a manual restart.
3. Scoped this to a Docker-only usage, since if a user tries to use podman with VS Codes Dev Contrainers they will waste a ton of time trying to get it to workable state (which is why I never added dev containers support).

Before committing this, tho I'd appreciate it If you could test that the changes I made to make sure it doesn't break your Docker set-up

[bpepple]

I saw your recent commit about podman being unreliable in VSCode. I'm happy you were able to test and see some issues. My own setup is VSCode and podman on Linux and I haven't had any issues getting Dev Containers to work.

You're running the container as root I assume? If a user wants to run it rootless, it's pretty painful to do with VS Code.

podman-compose, does not reliably not honor healthcheck-gated depends_on, so users can risking a migrate-before-DB-ready race (and all kinds of other ugliness). I ran into this constantly, and never could get the post-start.sh to not fail and had to the the dev server manually.

[Clearmist]

You're running the container as root I assume?

No. :) I'm running rootless.

I tested the changes you made and asked Claude for some help figuring out how to get rootless podman working in your environment.

I tested your changes and my new changes and they work for me. Will you please test again? There are now two compose yml files. One for Docker/OrbStack and the other for podman. Podman needs an extra declarative that Docker doesn't need.

I also fixed the server startup issue you mentioned in your commit message.

I appreciate you taking the time to review this pull request.

From Claude:

The Podman variant (docker-compose.podman.yml) layers on top of the shared docker-compose.yml and sets "updateRemoteUserUID": false. This exists because rootless Podman's UID namespace mapping otherwise conflicts with the bind-mounted workspace: the extension's own UID remap and Podman's default subordinate-UID mapping fight each other, so ownership of files under /workspace ends up wrong. docker-compose.podman.yml fixes this with userns_mode: keep-id, a Podman-only setting (not understood by Docker, hence the separate override file) that maps your host UID/GID directly into the container's namespace.

post-start.sh also fully detaches the dev server with setsid ... & disown rather than plain nohup ... &, since a background process launched from postStartCommand's exec session can otherwise get silently reaped once that session ends under Podman.

[bpepple]

I tested your changes and my new changes and they work for me. Will you please test again? There are now two compose yml files. One for Docker/OrbStack and the other for podman. Podman needs an extra declarative that Docker doesn't need.

I also fixed the server startup issue you mentioned in your commit message.

I appreciate you taking the time to review this pull request.

Partially... it run rootless, but you will still run into issues with the dev server needing to be manually started:

I still feel we need to make this Docker-only. The existing podman instructions are a much more bulllet-proof method to get a dev setup.

[Clearmist]

🤔 Hmm, okay. Well, if every step worked well in your setup except starting the dev server post create: how about adjusting the devcontainers readme to add a last step of running the dev server from the command line? I still think the automatic things this setup does and the major benefit of every developer having the same environment are large gains worth keeping.

Since you are much more familiar with this codebase I'll, of course, defer to your opinion. Do what you feel is best. 😊