The following warning appeared when starting devcontainer.
```
WARN[0000] /home/***/ghq/github.com/rails/rails/.devcontainer/compose.yaml: `version` is obsolete
WARN[0000] /tmp/devcontainercli-***/docker-compose/docker-compose.devcontainer.build-1720224621191.yml: `version` is obsolete
```
In fact, the top-level version element will be obsolete in the compose specification.
https://github.com/compose-spec/compose-spec/blob/master/spec.md#version-top-level-element-obsolete
And stop exposing the capybara server port to all interfaces.
We were using this just to make sure the selenium container can access
the capybara server but it can with the default bridge network.
This will make easier to make sure the service is running when the
development container is started.
Before after the first time the container was created, if it was
restarted you needed to run the boot.sh script manually to start the
service.
Previously, executing Active Record tests against the trilogy adapter
within a devcontainer would fail with the error message:
```
Trilogy::SyscallError::ENOENT: No such file or directory - trilogy_connect
- unable to connect to /tmp/mysql.sock (ActiveRecord::StatementInvalid)
```
Everytime I need to set up Rails locally on a new computer I have to
search for how to do this, then login to mysql, and run all these
commands.
In this change creating the rails user and running the grants is now
part of the `mysql` build rake task. This will default to using the
`root` user and no password. If this becomes problematic we can make it
configurable with env vars. I created the `rails` user twice for each
database defined even though the user is the same. This is in case we
decide to change it later on for arunit2.
This also updates the devcontainer for codespaces to use the rake tasks.
The container requires `sudo` so I had to provide an env var to make
that available.
