mon/OSDMonitor: fix double-free on old MOSDBoot

send_latest() does an m->put().

Backport: firefly, dumpling
Signed-off-by: Sage Weil <sage@redhat.com>
common/Finisher: fix perfcounter

Make sure we add in the nubmer of elements when we queue them
from a list or deque or vector.

Fix the type to be a counter.

Backport: firefly, dumpling
Signed-off-by: Sage Weil <sage@redhat.com>
mon: interact with MonitorDBStore::Transactions by shared_ptr Ref

TransactionRef everywhere!

Signed-off-by: Sage Weil <sage@redhat.com>
mon/MonitorDBStore: add close() method

Signed-off-by: Sage Weil <sage@redhat.com>
mon/MonitorDBStore: add async queue_transaction()

Do the transaction async, and then trigger a callback.

Signed-off-by: Sage Weil <sage@redhat.com>
mon/MonitorDBStore: drop useless ctor

Signed-off-by: Sage Weil <sage@redhat.com>
mon/MonitorDBStore: assert closed in destructor

Signed-off-by: Sage Weil <sage@redhat.com>
mon/Paxos: break commit() into two pieces

One part happens before the txn starts, the other after.  Move all of the
internal state update to the bottom half.  Eventually this will matter.

Signed-off-by: Sage Weil <sage@redhat.com>
mon/Paxos: move post-commit finish work into commit_finish()

The main change here is that we are merging the singleton and clustered
finish code together.  This is mostly a code shuffle, except for one
semantic change: we now trigger the commit waiters before finish_round()
in the singleton case, whereas before we did not.  I don't think there
was a specific reason why it differed from the clustered case.

Signed-off-by: Sage Weil <sage@redhat.com>
mon/Paxos: add writing and refresh states

The new transition will be

 (updating or updating-previous) -> writing -> refresh -> active

Signed-off-by: Sage Weil <sage@redhat.com>
mon/Paxos[Service]: allow reads during WRITING state

The REFRESH state is not readable; that's when we are re-reading our state
out of leveldb, and we hold the mon_lock during the period.  So, strictly
speaking, it doesn't matter whether we include it here since none of these
call sites would be visited while in that state.

Signed-off-by: Sage Weil <sage@redhat.com>
mon/Paxos: make backend write async

Move into the WRITING state and do the write to leveldb (or whatever the
backend is) asynchronously.

A few tricks here:
 - we can't do the is_updating() state check because we will always be in
   REFRESH.  Instead, make commit_proposal() tolerate the case where it is
   called but the top proposal isn't the one we just did (or the list is
   empty).  This makes the callers simpler.
 - do_refresh() may call bootstrap.  If we do bootstrap while in REFRESH,
   don't do a sync/flush on the backend store because *we* are async
   completion thread and we'll deadlock.  All other callers need to wait
   for this, though!

Signed-off-by: Sage Weil <sage@redhat.com>
mon/Paxos: flush io on reset()

Signed-off-by: Sage Weil <sage@redhat.com>
mon: flush before scrub

Signed-off-by: Sage Weil <sage@redhat.com>
mon: _reset() before updating state

In _reset() we call Paxos::restart(), which waits for commit completion,
and assumes the state hasn't been twiddled yet.

Signed-off-by: Sage Weil <sage@redhat.com>
mon/Paxos: WRITING != WRITING_PREVIOUS

This distinction is important: the update-previous state should not be
writeable, as reflected by PaxosService::is_writeable().

Signed-off-by: Sage Weil <sage@redhat.com>
mon: flush paxos write on shutdown

Signed-off-by: Sage Weil <sage@redhat.com>
test/mon/*: prime mon with initial command before injection

The osdmonitor_prepare_command is very fragile.  Send an initial command
to the mon beforehand.  This seems to prevent the initial command from
getting combined into an early mon proposal with some other stuff.

Alternatively, we could remove these tests and this mechanism entirely as
it is likely to great in the future when the next set of mon changes are
made, but they have shown themselves to be useful it catching other
regressions, so we'll patch them up for a bit longer.

Signed-off-by: Sage Weil <sage@redhat.com>
Merge branch 'wip-8639'

Reviewed-by: Joao Eduardo Luis <joao.luis@inktank.com>