feat: Add VS Code DevContainer for simplified development setup

[JohnRDOrazio]

Summary

• Add complete VS Code DevContainer configuration for one-click development environment setup
• Includes PHP 8.4, MariaDB, Dovecot IMAP, and Mailhog services
• Automatic database initialization, dependency installation, and configuration
• Pre-configured VS Code tasks for testing, linting, and development server
• Fix php-cs-fixer to exclude actual shell scripts while keeping PHP CLI scripts with .sh extension
• Add PHPUnit result cache to .gitignore

Closes #10084

Test plan

• Open repository in VS Code with Dev Containers extension installed
• Click "Reopen in Container" when prompted
• Verify all services start (MariaDB, Dovecot, Mailhog)
• Verify database is automatically initialized
• Start dev server with Ctrl+Shift+B and verify Roundcube loads
• Login with testuser/testpass credentials
• Run PHPUnit tests via VS Code task
• Run php-cs-fixer and verify it doesn't fail on shell scripts

🤖 Generated with Claude Code

[JohnRDOrazio]

I had to make some adjustments to static.php in order for it to work with the PHP built-in server, which proves useful for a dev environment without having to set up an apache or nginx server.

[JohnRDOrazio]

@alecpl may I ask your thoughts on this? I believe it would greatly simplify setting up a development environment, all within VSCode, so developers can just concentrate on working on issues and features without having to worry about setting up the whole environment.

[alecpl]

I don't like the duplication of docker images/setups. We already have some of it in the .ci folder. We also have https://github.com/roundcube/roundcubemail-docker repository. And I don't use any of it. Maybe @pabzm could take a look at it.

[pabzm]

I think we should not change static.php to fit PHP's webserver. If those changes are also beneficial in other setups I would suggest to post them in a standalone PR.

I use the development image from roundcube/roundcubemail-docker, which I consider sufficient.
@JohnRDOrazio Did you notice that image? What made you post a completely new implementation instead?

Personally I'm also not interested in VSCode-integration. And I'm skeptical about the AI-yness of the code and language. If several (potential) contributors are interested in this I would try to find the time for a thorough review, but without that noticeable interest I won't.

[alecpl]

Regarding the static.php part. We already have a few tests via tests/ServerTestCase.php implementation that shows it works with php server. So, if we want to change static.php code, I'd ask for some new tests in tests/Public/StaticTest.php.

[JohnRDOrazio]

You will both excuse me for the wait in the response, I have been travelling.

@pabzm I did look at the Docker Hub roundcube/roundcubemail:development image (the development image in roundcube/roundcubemail-docker, under the /development folder), but it's a run-from-source image rather than a development environment — it doesn't include testing tools (PHPUnit, PHPStan, php-cs-fixer, ESLint), has no Xdebug, no IDE integration, only supports SQLite, and doesn't provide IMAP/SMTP services for testing. The DevContainer here is meant to provide a complete development workflow: linting, static analysis, unit tests, debugging, and a full service stack (MariaDB, Dovecot, Mailhog) — all pre-configured and ready to go with a single "Reopen in Container" click.

The Docker Hub roundcube/roundcubemail:development image:

• Extends roundcube/roundcubemail:latest-apache-nonroot
• Adds npm, git, sudo, sqlite3
• Expects you to mount your source checkout at /var/www/html
• On startup: runs composer install, bin/install-jsdeps.sh, make css-elastic,
  bin/updatecss.sh, bin/initdb.sh
• Uses SQLite only, runs as www-data, serves via Apache

What it does NOT provide:

• No devcontainer.json
• No VS Code / IDE integration
• No PHPUnit, PHPStan, php-cs-fixer, ESLint
• No Xdebug
• No MariaDB/MySQL/PostgreSQL
• No IMAP server (Dovecot) or mail testing (Mailhog)
• No PHP extensions like pdo_mysql, ldap beyond what the production image ships

I'm not understanding in which manner a devcontainer or VSCode-integration relates to "AI-yness"? Developers can easily work within an IDE with or without AI code assistance. I myself have been writing PHP code for 15 years without any AI assistance; I find that tools like Claude Code can boost productivity and they are good at formulating commit descriptions / PR descriptions, saving a lot of time and energy for developers. That doesn't mean that developers should delegate the whole coding process to AI-assisted coding tools. Developers can and should inspect any code changes introduced by AI-assisted tooling in git diffs (which is quite easily done in an IDE such as VSCode, hence the purpose of this PR). Of course this PR does not enforce on developers the usage of one IDE over another, it simply allows developers that do use VSCode or similar IDEs (such as Eclipse Theia) to have a ready environment for development.

That said, I'm happy to discuss whether it makes sense to build on top of the official image as a base, or if there are aspects that could be simplified.

I would like to contribute a few PRs to the codebase, to the roundcube UI, but I was finding the environment setup a bit cumbersome. This PR would greatly simplify the process.

[JohnRDOrazio]

@alecpl @pabzm Thanks for the feedback on static.php. I can remove these changes and keep the current PR focused on the DevContainer itself.

Regarding the static.php improvements, I can open a separate PR that:

1. Fixes suffix-range handling (bytes=-500) which is currently treated as bytes=0-500 — this is a standalone bug fix independent of SAPI.
2. Adds the output buffer cleaning and SAPI-specific serving logic for PHP's built-in server compatibility.

I can include new tests in tests/Public/StaticTest.php covering the suffix-range fix and any other edge cases, building on the existing ServerTestCase infrastructure.

The reason for these changes was that the output buffering was NOT working in my PHP builtin server setup. After introducing the changes, the output buffering worked correctly. Here's a summary of the issues I encountered:

1. Content-Length mismatch (the ob_end_clean() fix)

   PHP's built-in server (php -S) can add output buffers that interfere with binary file serving.
   The Content-Length header says one size, but extra buffering causes the actual bytes sent to differ.
   This results in truncated or corrupted static assets (CSS, JS, images)
   — the browser receives incomplete files or hangs waiting for more data.

2. Suffix-range bug (standalone bug, not SAPI-specific)

   A request like bytes=-500 (meaning "the last 500 bytes") was treated as
   bytes=0-500 because the code set an empty $range[0] to 0. This is an RFC 7233
   compliance bug that affects all SAPIs, not just the built-in server.

3. Large chunk sizes causing issues with cli-server SAPI

   The original code used 512KB chunks (512 * 1024). PHP's built-in server handles
   output buffering and flushing differently from Apache/FPM — large chunks can
   cause the response to stall or be delivered incorrectly. The fix uses 8KB
   chunks with explicit flush() for cli-server, and the more efficient readfile()
   for production SAPIs.