Reduce number of malloc/free call in XMSS/external

[ducnguyen-sb]

Reduce number of malloc/free call in XMSS/external

Reason:

• There are plenty places in XMSS needs malloc/free (added to replace variable length array in C) that need to be checked each malloc call. in Add Stateful Signature (XMSS and LMS) #1650

Solutions:

1. Add each individual check each places or
2. Refactor the low-level functions to use temporary buffer provided by high-level functions.

Approach 1 is the easiest, but create too much overhead, and heap is slow.
Approach 2 require rewrite a bit function logic to allocate memory as buffer from high-level function to low-level function.

I select approach 2.

Should out of memory at crypto implementation exit the program?

This is a bit overkill, but I think it's very time-consuming task to rewrite the primitive crypto implementation.

1. When Out of Memory happen, the normal check is to make an early exit. By chance, this would make the primitive crypto continue to run and perhaps able to generate a signature.
   e.g: A hash tree requires memory allocation to compute the root, somehow the memory allocation fails, the root is returned with garbage value. Because it's hash, there is no way to distinguish random and garbage stack memory.
   Perhaps we should treat this as black box, when primitive crypto out of memory, EXIT the program.
2. This approach will make using a crypto primitive a pain in the ass to the application. Abrupt exit is normally unacceptable. But when it's out of memory, would we choose to stop generate crypto or.. continue to generate the incorrect one?

Of course these two problems can be solved if we refactor crypto primitives to return all the way to the top level like Rust language does. With C, I don't know how.

Okay, so that's why you see me use normal malloc and NULL check.
I can always switch to OQS_checked_malloc APIs in the XMSS/external.
Let me know.

Others

Some formats here and there to make astyle happy, and convert TODO lines to TODO (from upstream) because it's not from me.

• Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
• Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider will also need to be ready for review and merge by the time this is merged.)

[cothan]

@SWilson4 , can you take a look at this PR?