In some builds of libsoup3, multithread-test fails with a timeout, for
example:
in the past, where tests that use Apache fail with "Address already in
use: AH00072: make_sock: could not bind to address 127.0.0.1:xxx".

The failure mode that I have reported as a separate bug, where
multithread-test fails quickly with evidence of memory corruption, is
also out-of-scope for this particular bug report - although it might
turn out that their root cause ends up being the same.

To get an idea of how frequent this is, I tried these steps on the amd64
porterbox, barriere:

1. build libsoup3 (from unstable):

   schroot -c $chroot -r -- \
   env DEB_BUILD_PROFILES=noudeb \
   debuild -e CCACHE_DIR=$HOME/.ccache -e PATH=/usr/lib/ccache:$PATH -us -uc -B

2. run multithread-test repeatedly:

   schroot -c $chroot -r -- \
   env -C obj-x86_64-linux-gnu \
   DEB_BUILD_PROFILES=noudeb CCACHE_DIR=$HOME/.ccache PATH=/usr/lib/ccache:$PATH \
   DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 \
   meson test --repeat 100 -j1 multithread-test

   (I tried this 3 times; optionally add --timeout-multiplier=6 to the
   `meson test` command-line to emulate the original package build more
   accurately)

3. read obj-x86_64-linux-gnu/meson-logs/testlog.txt for details of the
   failures, if any

and my results were as follows:

- 7 successes, 1 timeout, 1 failure with memory corruption
- 19 successes, 1 timeout, 6 more successes, 1 more timeout, I cancelled
  the run at this point
- 10 successes, 1 timeout, 15 more successes, 1 failure with
  memory corruption

Anyone who wants libsoup3 tests to pass more often is invited to help to
debug and fix this. I cannot provide specific instructions for how to go
about this.

Annoyingly, it is not possible to run two or more copies of this test in
parallel, so that cannot be used to get to a failure sooner (this is
because each run of this test uses the same fixed filenames and port
numbers).

I am a member of the GNOME team, but not an Uploader of this particular
package. I am aware that some project members believe that, because I
have solved test issues it in the past, I should be held personally
responsible for every test failure that occurs in GNOME. As per the
Debian Social Contract §2.1.1, I decline that responsibility: I am not
able to fix everything all of the time, and I'm sorry if the project
considers my contributions to be inadequate.

    smcv