sec_mem: add note about the perf implications

Testing secure storage for ml-kem/dsa [1] shows performace penalty
when secure storage is enabled.

| Threads | baseline usec/handshake | secmem usec/handshake |
|---------+-------------------------+-----------------------|
|       1 |              586.784756 |            588.306131 |
|       2 |              599.537648 |            601.007393 |
|       4 |              610.663361 |            613.600663 |
|       8 |              649.347376 |            869.693358 |
|      16 |             1176.402781 |           2487.335286 |
|      32 |             2345.594618 |           5155.747515 |
|      64 |             4697.556045 |          11170.627031 |

the test shows that sec mem is ok-ish up to the number of available cores,
and when the sec mem lock gets contended, performance goes down rapidly.
Tested on Apple M4 Pro.

[1] https://github.com/openssl/openssl/pull/27625

Signed-off-by: Nikola Pajkovsky <nikolap@openssl.org>

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28011)

doc/man3/OPENSSL_secure_malloc.pod

@@ -45,7 +45,12 @@ the program's dynamic memory area, where keys and other sensitive
 information might be stored, OpenSSL supports the concept of a "secure heap."
 The level and type of security guarantees depend on the operating system.
 It is a good idea to review the code and see if it addresses your
-threat model and concerns.
+threat model and concerns. It should be noted that the secure heap
+uses a single read/write lock, and therefore any operations
+that involve allocation or freeing of secure heap memory are serialised,
+blocking other threads. With that in mind, highly concurrent applications
+should enable the secure heap with caution and be aware of the performance
+implications for multi-threaded code.
 
 If a secure heap is used, then private key B<BIGNUM> values are stored there.
 This protects long-term storage of private keys, but will not necessarily
@@ -135,7 +140,7 @@ a B<size_t> in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2015-2024 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2015-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy