test: fix setup of the postgres container used in tests

[trentm]

Refs: docker-library/postgres#1259

---

Around about October, tests started failing approximately like this:

...
$ make test
...
Tests are in progress, please be patient
1..5
ok 1 build image
not ok 2 create test container
...
 # -- command failed --
 ...
 #   dependency failed to start: container opbeans-node-postgres-1 exited (1)
 ...

E.g. this run: https://github.com/elastic/opbeans-node/actions/runs/19001948871/job/54269929994

I was able to reproduce locally, and the docker logs for the postgres container somewhat explains:

% docker logs opbeans-node-postgres-1
Error: in 18+, these Docker images are configured to store database data in a
      format which is compatible with "pg_ctlcluster" (specifically, using
      major-version-specific directory names).  This better reflects how
      PostgreSQL itself works, and how upgrades are to be performed.

      See also https://github.com/docker-library/postgres/pull/1259

      Counter to that, there appears to be PostgreSQL data in:
        /var/lib/postgresql/data (unused mount/volume)

      This is usually the result of upgrading the Docker image without
      upgrading the underlying database using "pg_upgrade" (which requires both
      versions).

      The suggested container configuration for 18+ is to place a single mount
      at /var/lib/postgresql which will then place PostgreSQL data in a
      subdirectory, allowing usage of "pg_upgrade --link" without mount point
      boundary issues.

      See https://github.com/docker-library/postgres/issues/37 for a (long)
      discussion around this process, and suggestions for how to do so.

The docker compose files for this repo are currently using postgres:latest. So when the 'latest' tag moved to v18 which included this breaking change, then tests started failing.
This change implements the suggestion from the comment above:

The suggested container configuration for 18+ is to place a single mount
       at /var/lib/postgresql which will then place PostgreSQL data in a
       subdirectory, allowing usage of "pg_upgrade --link" without mount point
       boundary issues.