using palloc/pfree for OpenSSL allocations with CRYPTO_set_mem_functions

I noticed that OpenSSL has a CRYPTO_set_mem_functions
<https://www.openssl.org/docs/man3.2/man3/CRYPTO_set_mem_functions.html>
function:

If no allocations have been done, it is possible to “swap out” the default
> implementations for OPENSSL_malloc(), OPENSSL_realloc() and OPENSSL_free()
> and replace them with alternate versions.
>

But a different technique is used in contrib/pgcrypto/openssl.c
<https://github.com/postgres/postgres/blob/REL_16_STABLE/contrib/pgcrypto/openssl.c#L52-L56>
to work around the different allocation system of OpenSSL:

To make sure we don't leak OpenSSL handles on abort, we keep OSSLCipher
> objects in a linked list, allocated in TopMemoryContext. We use the
> ResourceOwner mechanism to free them on abort.

I see the particulars might have changed on the master branch though!

CRYPTO_set_mem_functions must be called *before* any uses of malloc/free
though, so I believe it needs to be called right after the OPENSSL_init_ssl
<https://www.openssl.org/docs/man3.2/man3/OPENSSL_init_ssl.html> calls
(e.g. in src/backend/libpq/be-secure-openssl.c
<https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/libpq/be-secure-openssl.c#L102>
and src/interfaces/libpq/fe-secure-openssl.c
<https://github.com/postgres/postgres/blob/REL_16_STABLE/src/interfaces/libpq/fe-secure-openssl.c#L858>)
for this to be possible.

Would it be desirable to do this? If not, why is the TopMemoryContext
approach a better option? I do not understand the code quite well enough to
evaluate the tradeoffs myself yet!

Best,
Evan

P.S. Searcthing all time with this query
<https://www.postgresql.org/search/?m=1&q=CRYPTO_set_mem_functions&l=&d=-1&s=r>,
I found one thread in 2018 that mentions CRYPTO_set_mem_functions, but in a
different capacity. I hope I did not miss some other mention of it on the
email lists!