UtAssert improvements for multiple test invocations

[jphickey]

Is your feature request related to a problem? Please describe.
UtAssert currently assumes that there will only be one test set to execute. After booting, a set of tests is collected, then executed, and once the test is complete the process will end (either by simply exiting the process on Linux debug environment, or stopping the parent VM/container, or doing a processor reset if on real hardware).

The newly added CFE functional test now permit more than one test set to run, based on commands. A test can be started, completed, and then another test can be started, all in one "lifetime" of the UtAssert global data structures.

Although this generally works there could be some improvements

Describe the solution you'd like
At the end of a test run the list is destroyed, and it leaves the list pointer as NULL. This means no additional tests can be registered after a call to UtTest_Run. (Luckily re-invoking UtTest_EarlyInit is a workaround - this is risky though because if any tests were in the list already, early init will drop them and leak the memory, it does not check for this). Preferably this should leave the structure in a state where more tests can be registered without a complete re-init.

Additional context
Neither of these suggestions are critical at this time - would be nice to have, but nothing that prevents CFE functional test from basically running, using the workaround of re-invoking UtTest_EarlyInit() between every test cycle.

The biggest risk is the fact that re-invoking UtTest_EarlyInit does not protect against clobbering already-registered tests, but this shouldn't happen if the proposed test pattern is followed (its more of something that isn't protected against happening, not something actually happening).

Requester Info
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

Another area for potential improvement - the UtAssert data structures and counters are not thread-safe, the library does not have any sort of built-in mutex. It was not needed as most test programs are single threaded, and the OSAL tests that did invoke multiple tasks could consolidate all asserts into a single task, so it was not a problem.

CFE environment is fundamentally multi-threaded. This is worked around in the cfe_assert wrapper library by putting a mutex in there, and ensuring that all test programs get the mutex before doing asserts.

It would be preferable if UtAssert were internally thread-safe so this wouldn't be needed.

[jphickey]

Split this ticket in half - issue #1061 is to protect the global data structures/counters with a mutex, therefore make them thread safe (second part of initial summary)

Changing the data structures to allow for multiple test invocations is likely a more substantial change, so it can be deferred.