mon: MDSMonitor: wait for osdmon to be writable when requesting proposal

Otherwise we may end up requesting the osdmon to propose while it is
mid-proposal.  We can't simply return EAGAIN to the user either because
then we would have to expect the user to be able to successfully race
with the whole cluster in finding a window in which 'mds fs new' command
would succeed -- which is not a realistic expectation.  Having the
command to osdmon()->wait_for_writable() guarantees that the command
will be added to a queue and that we will, eventually, tend to it.

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
mon: Paxos: only commit proposal in commit_finish if quorum is gone

When an election is triggered we will call Monitor::_reset(), which in
turn will call Paxos::restart() which will wait for all in-flight
writes to the store to be finished.

However, upon finishing a store commit we would eventually call
commit_finish(), which would kick off waiters and queue a new proposal.
Given that the quorum is no more (given we already cleared it when we
started a new election), we would not be able to propose a new value
due to lack of quorum (thus triggering asserts on Paxos::begin()).

This way we make sure that we only commit the proposal to disk and
proceed to return if the quorum is gone.

We should be safe from having become a peon in the mean time though.

We should only arrive to this code path when finishing an async store
write; and we actively wait for the store to flush all the in-flight
writes before returning from Paxos::restart().  We will have the
guarantee that we have not yet moved on to the proper election phase by
the time we are finishing the writes, thus we haven't yet given the
chance for the election to go through and deciding that we are after all
a peon -- for all it's worth, during the whole time we're finishing
writes we still consider ourselves as the One True Leader.

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