There are rare reports of libvirt deadlocking itself which show a
fork'd, but not exec'd, child process stuck in localtime_r(). This
is because localtime_r() is not an async signal, so if we happened
to fork() at the exact time another thread was calling localtime_r()
we could get stuck with a stale lock in the child.
Although we go to pains to protect the libvirt logging code by
acquiring the mutex before forking, this is not sufficient, because
some non-logging related code could invoke virTimestamp() which
calls localtime_r() too.
The only sane approach to fix this is to make our timestamp
generation APIs thread safe, by doing a clean impl of gmtime()
and strftime() inside libvirt using static buffers and only async
safe POSIX apis.