at least I now realize that this could probably be misunderstood...

The dance of taking a reference when waiting caused a lot of trouble
already before, and with a fresh look at it does not seem to make much
sense. But most importantly, it was wrong:

lbuf->ff was set to NULL in logbuffer_flush_finish_work_one() before
the mutex was returned with pthread_cond_wait(), so

	if (ff == NULL)
		goto unlock;

in logbuffer_wait_flush_fini() could lead to the function returning
before logbuffer_flush_finish_work_one() _was_ actually done.

But with bceec122 this could lead
to the stack memory being repurposed (logbuffer_flush_finish
returning) before it was actually safe to.

This issue could surface in fellow_log_test hanging.

We also now return all allocations under the lock to prevent a race
with fellow_log_close() where flush finish threads could outlive the
ffd, resulting in buddy leak detection to fire, because the ff
allocation was not returned.

Fixes #49

The other assertion is what we actually mean:

The log2up(sz) must be at least bits, otherwise it makes no sense.

otherwise all hell will break loose if we changed reqs->pri, because
we would dequeue from the wrong list head.

The single-allocation buddy wrapper functions did not serve much of a
purpose but waiting for FP_OPEN, which has now been moved to
fellow_dskbuddy().

Fixes #48

... a chance to take memory from the old

otherwise we would hold onto log blocks for a long time, possibly until
the next ref'ing flush. This could cause lock ups due to no memory being
available.

This is considered a major contribution towards fixing the lockup issues
documented in #41

kick the logwatcher first before potentially running into a synchronous
flush.