osd: tolerate racing threads starting recovery ops

We sample the (max - active) recovery ops to know how many to start, but
do not hold the lock over the full duration, such that it is possible to
start too many ops.  This isn't problematic except that our condition
checks for being == max but not beyond it, and we will continue to start
recovery ops when we shouldn't.  Fix this by adjusting the conditional
to be <=.

Reported-by: Stefan Priebe <s.priebe@profihost.ag>
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: David Zafman <david.zafman@inktank.com>
(cherry picked from commit 3791a1e55828ba541f9d3e8e3df0da8e79c375f9)
vstart.sh: set run_dir to out

This avoids annoying errors about creating /var/run/ceph from
init-ceph.

Fixes: #4036
Signed-off-by: Sage Weil <sage@inktank.com>
(cherry picked from commit 3e707da443540d86c9fd480fe7e2d2fbda8c0f3f)
osd: fix race when queuing recovery ops

Previously we would sample how many ops to start under teh lock, drop it,
and start that many.  This is racy because multiple threads can jump in
and we start too many ops.  Instead, claim as many slots as we can and
release them back later if we do not end up using them.

Take care to re-wake the work-queue since we are releasing more resources
for wq use.

Signed-off-by: Sage Weil <sage@inktank.com>