Fix zil_commit() deadlock

If two threads concurrently enter zil_commit(), one will take the
zilog->zl_lock mutex (lets call this thread A) while the other will
block (lets call this thread B). Thread A will then set a flag saying
that there is a writer and free the mutex. Thread B will get the mutex,
see the flag and enter a condition wait for a signal from thread A that
it finished. Then before thead A sends the signal, it will attempt to
take the mutex. The two threads will then wait on each other ad
infinitum and forward progress on the pool will stop. We break the
deadlock by making thread A stop trying to retake the mutex. When
thinking about safety, there are no cases to consider. The first is that
there is a thread B. In that case, this is safe because thread B will
not act until signaled by thread A, giving thread A effective control
over the mutex. If there is no thread B, then we do not have to worry
about another thread and this is still safe.

Signed-off-by: Richard Yao <ryao@gentoo.org>