Fix race condition in scheduler reset

[csegarragonz]

In this PR I fix a race condition when resetting executors that made the flushing tests in faasm segfault sporadically.

The race condition happened between:

• The main thread calling Scheduler::reset() then Executor::finish and, for each thread in threadPoolThreads: (1) check not null, (2) enqueue shutdown task, (3) join.
• The thread pool thread that: (i) times out dequeueing between (1) and (2), (ii) breaks out the main executor loop setting selfShutdown = true and assigning itself to null; all of this before (3).

The consequence was that we tried to join a nullptr in (3) and segfault.

The proposed solution changes the order in the Executor::finish loop to: (1) enqueue shutdown task, (2) check if thread is null, (3) if not join the thread. This way, when we start killing the thread pool, the thread either: (1) is still blocked dequeuing, thus adding the POOL_SHUTDOWN task will have the desired effect when it wakes up, or (2) has already timed-out, and will self-destroy itself, and will be pointing to null when we check for it.

I think the chances that the thread has timed out when we enqueue but it is not null when we check and is null when we join are very remote as there's only one instruction between timing out and setting oneself to null, and I haven't been able to re-create it.

Note that the tasks queues are cleared at the end of Executor::finish so it is not really a problem having non-empty queues with POOL_SHUTDOWN tasks.

I also include a test that makes the current master branch crash with less than 20 tries (less than 10 in fact the 20 times I tried locally), but passes now.

[Shillaker]

This could end up being quite a long sleep depending on the default config, and it's multiplied by 20, so it would be good to set this to something very short at the start of this test (e.g. 100ms).

[csegarragonz]

Good point, thanks