Introduce Espressif wolfcrypt warmup

[gojimmypi]

This is the Espressif-specific version of #9203

I tend to agree that this may not belong in the wolfCrypt_Init(), but the code does need to be available and consistent.

I plan to use this in all the Espressif examples.

Description

Adds a esp_sdk_wolfssl_warmup() warmup, call as desired, enabled by default, disable with NO_WOLFCRYPT_WARMUP.

To use, call this early in the application startup:

int ret;
ret = esp_sdk_wolfssl_warmup();

Reason

The random number generator and AES functions were observed allocating long term (perhaps permanent?) heap memory. This PR "warms up" wolfCrypt by calling some sample code early, ensuring (hoping?) any heap allocations are at the edge of the heap and not in the middle.

A long term heap allocation in the middle of the heap, say after reading a large object such as a certificate, may interfere with the long term maximum memory availability.

This PR also makes the wolfcrypt test result more pretty.

Background

I've been optimizing wolfssl for small embedded targets. Some time ago, I introduced a heap discrepancy alert in the wolfcrypt tests. It was intended to find memory leaks after repeatedly running the tests, for example #8506

See the wolfcrypt/test/test.c around line 154 for the PRINT_HEAP_CHECKPOINT implementation for WOLFSSL_ESPIDF targets.

There's been a nagging reminder in the tests:

...
RANDOM   test passed!
I (1351) wc_test: Breadcrumb: TEST_PASS
W (1351) wc_test: Warning: this heap 437488 != last 437576
...
HPKE     test passed!
I (17095) wc_test: Breadcrumb: TEST_PASS
W (17095) wc_test: Warning: this heap 437400 != last 437488

As it only occurs on the first pass of these tests, I did not consider it a memory leak. Still, it's not pretty. But until recently "not pretty" did not warrant attention. Until recently when considering the location of the heap object and no memory available even with a seemingly large quality of total heap space.

Fixes zd# n/a

Testing

How did you test?

Tested locally on ESP32 targets

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[devin-ai-integration]

🛟 Devin Lifeguard found 2 likely issues in this PR

• check-return-codes snippet: Preserve earlier errors by returning immediately (or keeping the first non-zero code) instead of overwriting ret after the RNG section; e.g. only call wc_FreeRng and the AES warm-up when ret == 0 and return the first error encountered.
• use-sizeof snippet: Replace the literal 1 in wc_RNG_GenerateBlock(&rng, &dummy, 1); with sizeof(dummy) to remove the hard-coded size.

@gojimmypi
please take a look at the above issues which Devin flagged. Devin will not fix these issues automatically.

[gojimmypi]

Jenkins retest this please.

For Cannot contact wolf-linux-cloud-node-[n]: java.lang.InterruptedException java.io.StreamCorruptedException: invalid stream header: 636F7272
‘wolf-linux-cloud-node-[n]’ is offline

[dgarske]

Were you able to identify the heap memory that was allocated and left allocated by AES/RNG? Is it a large allocation? I don't think this PR to do warm-up is the right solution. Again sounds more like a workaround. The right solution is finding out what heap memory is allocated and not free'd. Then solving use of it. I am certain if its in wolfCrypt we have build options to resolve it. If its in the ESP crypto layers than its a different problem and consider calling ESP API's to init/warm up, not code in wolfCrypt.

[gojimmypi]

Were you able to identify the heap memory that was allocated and left allocated by AES/RNG?

Not yet.

Is it a large allocation?

No, just enough to spoil a later large allocation.

sounds more like a workaround

Agreed.

ESP crypto layers than its a different problem and consider calling ESP API's to init/warm up

Probably.