gh-158868: Reduce ASLR in the MSan CI job

[StanFromIreland]

This fixes the bug reported in #158868, rather than skipping the job.

To reproduce this locally:

$ sudo sysctl vm.mmap_rnd_bits
vm.mmap_rnd_bits = 28
$ for i in $(seq 300); do
  MSAN_OPTIONS=verbosity=1 ./python -m test test_os.test_posix -m test_fexecve 2>&1 \
    | grep -E 'execve failed|incompatible' && { echo "failed on run $i"; break; }
done
$ sudo sysctl -w vm.mmap_rnd_bits=32
vm.mmap_rnd_bits = 32
$ for i in $(seq 300); do   MSAN_OPTIONS=verbosity=1 ./python -m test test_os.test_posix -m test_fexecve 2>&1     | grep -E 'execve failed|incompatible' && { echo "$i"; break; }; done
==35706==WARNING: MemorySanitizer: memory layout is incompatible, possibly due to high-entropy ASLR.
execve failed, errno 2
4

We actually already do this for the TSan job, it seems we got unlucky on the PR that added MSan:

cpython/.github/workflows/reusable-san.yml

Line 49 in 508db6d

sudo sysctl -w vm.mmap_rnd_bits=28 # Reduce ASLR to avoid TSan crashing

In the test, the mappings of the exec'd child sometimes land where MSan needs its shadow memory, so the MSan runtime disables ASLR and re-executes the process at startup, which fails because the child was started from a close-on-exec file descriptor.

[vstinner]

LGTM. It seems correct to reuse the same configuration than then TSan job.