Migrate TW image to Alma9, maintain OS and Python version homogeneity with Schedd (AP's), support Py3.9 → Py3.12

[nausikt]

As Stefano pointed out in #8956 (comment),

Given that

• WMCore and CRAB code are "feature frozen" now
• alma9 will have security fixes (and hence be usable as container base) until 2032
• python 3.9 is and will always be the python version in Alma9 and Schedulers (AP's) already used them.

move TW image to use Alma9 container as base, instead of python3.8 Debian one

Currently, our TW image basically derived from wmagent-base which in time of wmfreeze has Debian 13 (Trixie) underneath as First class base OS-support by WMCore team.

CRABServer/cicd/crabtaskworker_pypi/Dockerfile

Lines 38 to 40 in 620a01c

	# start image
	FROM registry.cern.ch/cmsweb/wmagent-base:pypi-20230705
	SHELL ["/bin/bash", "-c"]

**there is no alma9 build support by WMCore team yet in this wmagent-base layer, as we can see in harbor/wmagent-base**
N.B. Debian Trixie shipped py3.13 as default, on the other hand Alma9, as a rebuild old RHEL, will officially support py3.9 up-to py3.12 in its default package repositories, further py3.13++ having to be installed from source manually. BUT py3.9 is just fine for our context now.

---

AFAICS, we have 3 options to adopt Alma9 in TW could be Either

• [1] Ask WMCore team for wmagent-base:alma9-py3.9--YYMMDDDD build.

OR try to derive from lower layer image ourself. i.e.

• [2] dmwm-base (where wmagent-base derived from, See also wmagent-base/Dockerfile)
  5 months ago, Alma9 has been support in this layer via alma9-based Dockerfile.
  we can see that harbor/dmwm-base have alma9-py3.12-20250728-stable and alma9-py3.9-20250703-stable available for us.

So, if we work on top of this layer we can switch OS and py3.9 -> py3.12 (if AP's was promoted to py3.12 later in the future, we can aligned TW again here) pretty easily via just changing the tag, meanwhile we can have some dmwm's conventions + grounded work out of the box.

Note: Be aware that we still need to install oracle client, set paths, linking libs a little bit ourself , which used to be handled by wmagent-base, where oracle client was provided by Valentin's cmsweb/oracle which been built in debian based env,
So, here i have no confident that we can copying oracle artifacts across OS-env, and things will magically work out here or not.

• [3] cmsweb-alma9-base (See also harbor/cmsweb-alma9-base, Dockerfile]
  where some CMSWEB required certs & packages was addressed. BUT this image have NO grounded work from dmwm team, so we have to re-established some civilisation ourself from almost scratch.

---

My First Glance call
In January, i see ourself going with [2], not bother WMCore team, instead we open PR to help them support wmagent-alma9-base for whole dmwm since someone in dmwm have to get [2] done anyhow?