Server thread safety

[bigbrett]

TL;DR: Makes wolfHSM server safe to use in multithreaded scenarios.

Overview

This pull request implements a generic framework for thread-safe access to shared server resources in wolfHSM, specifically targeting the NVM (non-volatile memory) and global key cache subsystems as the first shared data to be protected. Crypto is left to a subsequent PR but is the likely next candidate.

Note that a server context itself still cannot be shared across threads without proper serialization by the caller. This PR just adds the mechanisms such that, when multiple server contexts share an NVM instance or global keystore, access to those shared resources is properly serialized, allowing requests from multiple clients to be processed concurrently in separate threads.

Changes:

• Introduces lock abstraction layer (wh_lock.{c,h}) with callback-based design for platform independence
• Example POSIX lock implementation using pthread_mutex
• Refactor NVM and keystore layer internals to use lock abstraction such that global keystore and NVM can be shared by multiple server contexts in a thread-safe manner
• Thread safe functionality enabled with the WOLFHSM_CFG_THREADSAFE build option. When this option is NOT defined, all lock abstraction operations compile to no-ops, with zero overhead
• Adds "thread safe stress test" to test suite that attempts the flesh out data races via a large number of contention cases, meant to be run under ThreadSanitizer

Gaps/future work:

• Serializing access to global crypto state, specifically hardware crypto for ports. A bit of a tricky problem since offload is provided at the port level, and there isn't a good way for wolfHSM to know which algos will be accelerated and which wont. A naive implementation might consider simply locking the server crypto context, but this contains a mixture of local (CMAC) and quasi-global (RNG) elements and no abstraction for hardware. Locks also need to be synchronized with the wolfCrypt port mutex. We should refactor the server crypto context and perhaps split it into local and global structures, with the global supporting hardware state. Future work....