python3.6 test_ssl fails reliably on systems under load

$ autopkgtest-buildvm-ubuntu-cloud --arch i386

put system under load; e.g. pull-lp-source boost1.67; cd boost1.67; DEB_BUILD_OPTIONS=parallel=12 ./debian/rules build should do it, on an 4core/8hypercore system

$ autopkgtest -s --shell --apt-pocket=proposed --apt-upgrade python3.6 --test-name testsuite -- qemu -c 1 -q qemu-system-i386 ./autopkgtest-cosmic-i386.img

test_ssl fails

To rerun test_ssl alone, one can do:
$ python3.6 -W default -bb -E -R -m test -j 1 -w -uall,-network,-urlfetch,-gui test_ssl --verbose

in a racy manner, for many test cases, due to ConnectionRefused from the TestEchoServer

One way to solve this is to reduce the load, cause without load TestEchoServer keeps up just fine.

Symptoms are s.connect failing with ConnectionRefusedError, or for example s.getpeercreds failing with Transport not connected.

I'm not sure it's worth any time fixing this test-server implementation, as clearly it is testing the ssl server/client bits, that work correctly on a normal, not-under-stress systems. And thus the ssl bits are correctly validated.

I will try to create a reproducer which does not involve VMs and stressing host.

meanwhile it would be nice to run python tests on slightly bigger machines, e.g. mark it as big_packages.