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. The second is that there is no thread
B. In that case, this is safe because we do not need to worry about
another thread.

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