POC For docker compose
- [X] closes #46532 

POC using docker compose, which is also used by the arrow project. 

The idea here is that we can simply run `docker compose build db-testing` to build an image with postgres (can later add mysql) and our minimal development requirements then `docker compose run --rm db-testing` to run relevant tests. This can be done both by a developer as well as on GH actions.

This still needs a bit more work as it currently muddles user permissions on the host when building pandas

cc @jonashaag who looks to have been doing some awesome work on CI lately
I am in favor of having what users tests locally use the same setup as what the CI runs which containers help enforce.

We should keep in mind that Docker is a freemium tool (limited Dockerhub pulls over a period of time albeit maybe hard to hit & some free container registries out there).

I'll be interested to see how we can leverage docker-compose with the CI providers - initially my gut feels it might just be a lateral move - and maintain testing coverage across different platform versions. We're almost at the point where we can say

```
for platform in [windows, mac, ubuntu]:
    for python_version in [3.8, 3.9, 3.10]:
        test with platform + python_version + all required & optional dependencies
```

I would suggest the docker-compose POC mirrors the jobs that GHA currently runs for an easier comparison to our current CI setup. So in terms of testing, all tests can be run for a particular platform + Python version.  Awesome feedback. The one area where docker is definitely an upgrade over current CI is reproducibility as an end user. GHA are good but AFAIK not something you can reproduce locally. I think the DB tests in particular are an area where we struggle with that

In the future there might also be a use case where we create base images for minimum pinned versions and always reference them, rather than building from scratch in GHA every time. This could help reduce build / test times a bit

We already have this with the existing Dockerfile, but if we roll that into compose we can have a consistent way to create a DEV environment (especially for new users) that our current CI can't help with > I am in favor of having what users tests locally use the same setup as what the CI runs which containers help enforce.

+1 So this works now with a simple `docker compose up` - starts both DB services and runs all the tests
 Punting for now. Can reopen if it becomes more clearly useful