gh-156228: Use PyMem_Raw* allocators for OpenSSL in _ssl and _hashlib

[kumaraditya303]

import tracemalloc, ssl, hashlib
tracemalloc.start()
ctx = ssl.create_default_context()      # heavy OpenSSL work
h = hashlib.new('sha3_512')             # one EVP context

traced by tracemalloc	without PR	with PR
ssl.create_default_context()	2.4 KB	1.27 MB
one sha3_512 context	48 B	624 B

• Issue: Use PyMem_Raw* allocator for OpenSSL in _ssl and _hashlib #156228

[kumaraditya303]

I'd like to merge this by weekend if there are no objections, I've posted the performance analysis on the issue.

[gpshead]

I'm not sure we can do this safely. tracemalloc_alloc calls PyGILState_Ensure() within PyMem_Raw allocations, OpenSSL allocates memory with its own internal locks held, and we call into OpenSSL in many circumstances with the GIL released.

[kumaraditya303]

There is ongoing discussion on tracemalloc regarding this in #155725 but I don't think it causes deadlocks, in worst case it causes contention but that is the cost of using tracemalloc.

[gpshead]

If we were always consistent about releasing the GIL when calling into openssl APIs across _ssl and _hashlib it should avoid deadlocks... but I don't think we are.

And other extension modules calling libssl APIs might not and we cannot control that. So I don't think we can do this at all.

I let Claude hunt for an example where we don't... its found one and written a deadlock reproducer when using our PyMem_Raw allocators with OpenSSL - deadlocks on regular and free-threaded builds. Reproducer with explanation gist.