fix: mark tests expecting malloc to fail as opt-in

[CertainLach]

Those tests might overload machines with huge amount of RAM or with overcommit enabled, because of that - one test was already disabled on darwin, which enables overcommit by default.

Because of the potentially destructive overhead, I believe they should be opt-in.

Ref: Read the comments in #14782

[CertainLach]

Cc: @alex as the author of #14782

[alex]

Is there a particular place this is causing a problem, or just in theory? Tests should (probably must ) be on by default to be effective, so I don't want to disable things by default without an exceptionally good reason.

[CertainLach]

Is there a particular place this is causing a problem, or just in theory?

This test was already disabled on darwin, and it fails on any linux machine with overcommit enabled (sysctl -w vm.overcommit_memory=1)/machines with >4TiB of memory, because malloc never fails in this case, process is getting killed by OOM Killer without MemoryError being thrown.

I have noticed this problem because I was getting OOM during this package build in NixOS, but this may happen regardless of the distribution, the original PR has a comment telling about the OOM on Gentoo machine.

This test should not be run by default, because by spec, malloc only fails in case of system is unable to allocate memory, but with overcommit memory allocation always succeeds, regardless of the size.

[alex]

I'd be happy to consider a PR that checks the sysctl for overcommit and skips in those cases, but right now this PR makes these tests less useless for the developers of this software.

[CertainLach]

I'm not sure if checking sysctl is a good idea here, it might not be available in docker/with selinux/other sandboxing, while explicit --enable-malloc-failure allows the developer to manually specify the behavior they expect... This is also a source of impurity, as some sandboxes might expose this value, but then expect deterministic set of tests to pass, but I'm not sure if that would affect anyone.

Better behavior in my opinion would be trying to allocate 4TiB block, and then skipping pytest.mark.malloc_failure depending on this allocation succeeding or not, but it would still fail on machines with 4TiB+ RAM (But I'm fine if this is the accepted solution, I don't have 4TiB of RAM to be affected by that :D) - Actually, it won't, since we would disable this test for such machines and treat them as overcommitting, which is good, since it is not good when one test might occupy this much RAM.

[CertainLach]

Implemented, but have not tested yet the second solution I proposed (probe for overcommit, skip tests if environment allows overcommits)

Just to be clear - OOM happens not because of malloc, but because it actually uses the allocated memory, so this probe won't cause the same problem

[CertainLach]

CI was failing on armv7l with OverflowError here, because 4TiB can't be converted to ssize_t (2GB) on 32bit platforms
I don't think it makes sense to check for overcommit in such cases, all the malloc failure tests allocate much more that 2GB already and will never fail on overcommit enabled on 32bit platform

[CertainLach]

Tested in overcommiting environment - the test gets properly skipped, and I don't see it being skipped in CI, so everything seems to be fine

[CertainLach]

Also found out two downstreams were already disabling one of the failing tests, exactly because of overcommits:

NixOS/nixpkgs@b8e8ef2

https://github.com/gentoo/gentoo/blob/f96c060220bb94c22f417d42bc9933843af18b45/dev-python/cryptography/cryptography-48.0.0.ebuild#L140

With the new pytest mark added, new such tests would no longer be disruptive for maintainers