Bintar deps validation script

[cvicentiu]

This commit introduces two different validation scripts.

• One that checks dependencies of ELF files in bintar archives.
• One that does a smoke test on bintar archives:
  Goes through each supported distribution and starts a bare-bones
  container image. Then within the image it does:
  1. Extract the archive mariadb-install-db
  2. Run ./mariadb-install-db
  3. Start ./mariadbd as a process inside the container
  4. Use the ./mariadb client from the archive to connect and run
     SELECT VERSION().

[RazvanLiviuVarzaru]

@cvicentiu
It might be early to discuss this but I think it's important for avoiding future refactoring.
I hope you are willing to briefly agree on the delivery method of these scripts.
@fauust this discussion might interest you.

As you know, the workers run different Python versions depending on the Host operating system and these scripts come with a bunch of requirements to be installed beforehand. This can make the maintenance, delivery and installation a pain point.
Of course, we can work with virtual environments, find the best installation method, but the effort is still there and it's the CI spending time on it.

For deps_test.py I have the following idea:

• this script can easily be included in a Docker image, where we pin the python version and the dependencies. This reduces the complexity of delivering it to a variety of worker host systems.
• given that in the future we will use buildbot non-latent workers, launching this script can be as easy as setting the Dockerfile entry-point to ENTRYPOINT ["python", "deps_test.py"] and then docker run #IMAGE# #args# (of course mounting the path where the binary tarball was produced in a previous step).

For smoke_test.py the problem is not that easy if, let's say, we go by the same principle I presented for deps_test.py

• there is something I never explored which is Docker-in-Docker https://hub.docker.com/_/docker but can be a potential solution
• another solution I can think of is mounting the docker socket and let the script control docker on the host from within a container

Let me know what are your thoughts,
If creating a container image sounds interesting to you, I'm willing to help and create the Dockerfiles.

[RazvanLiviuVarzaru]

@cvicentiu I've added a Dockerfile to build two images for deps and smoke tests
5f517b3

deps approach is pretty elegant, with no major workarounds.

Instead for smoke tests, the Docker-Out-Of-Docker method have several constraints:

• mounting docker socket
• --test_directory is mandatory and the mounted paths host:container should be symmetric so that MariaDBContainerRunner bind mounts the right host path into test containers.
• there are some leftover dirs after a run, the tests base dir, and a dir for each test container (datadir). And unfortunately these are owned by root and cannot be removed by buildbot-worker for example

See the commit message for details.