Fix crash and deadlocks in the support for recursive logging

[Smjert]

The code has been slightly refactored to remove an incorrect usage
of std::futures in a queue, where it was possible to try to wait on the
same std::future twice, which would lead to a crash.

Even after fixing the crash, it was possible that threads dealing
with recursive logging would change order and wait on a std::future
of another thread, causing a deadlock.

Finally the deferred log relaying wasn't always used when it should've,
due to a confusion between boolean values.
A enum class has been used instead to be more expressive about
the relaying mode asked.

Fixes #6928

[theopolis]

Is there a potential for a future to exist while osquery is shutting down?

[Smjert]

Is there a potential for a future to exist while osquery is shutting down?

I'm not sure I understand your question; meaning, the optional future is not empty as long as there's "a thread" (but a very specific one, closely related to the one that waits) that needs to do deferred/async logging.

So it may be set when osquery is asked to shutdown and a thread is waiting on it, but I expect the deferred logging thread to return/yield as usual, so the future can immediately stop waiting.