Fix: Resolve race condition in HSI generator worker thread startup

[MRiganSUSX]

Problem

A race condition exists during the startup of the FakeHSIEventGeneratorModule. The do_start method initializes the TimeSync receiver and then immediately starts the do_hsi_work worker thread.

The worker thread's first action is to wait for a TimeSync message. However, there is no guarantee that the receiver is fully configured and ready by the time the worker thread starts waiting. In a scenario where the worker thread starts faster than the receiver can initialize, the first TimeSync message can be missed, potentially leading to a deadlock.

The existence of this race condition was confirmed by adding a temporary sleep at the beginning of the worker thread was sufficient to prevent the deadlock, proving it is a timing issue.

Solution

This change introduces an explicit synchronization mechanism using std::promise and std::future to resolve the race condition.

The new workflow is as follows:

• In do_start, a std::promise is created before any setup begins.
• The do_hsi_work worker thread is started. Its first action is to get the std::future from the promise and wait() on it, which blocks the thread from proceeding.
• The main thread continues its execution in do_start, completing all initialization (setting up the timestamp estimator, adding the receiver callback, etc.).
• Once all setup is complete, do_start calls set_value() on the promise.

This action fulfills the future and unblocks the worker thread, which can now safely proceed, guaranteed that all resources are fully initialized.

[bieryAtFnal]

I have been unable to reproduce this issue, and I haven't been able to understand Michal's proposed changes yet, so we'll defer this, for now.