mon: improve osdmap subscription debug output

Signed-off-by: Sage Weil <sage@inktank.com>
Revert "mon/OSDMonitor: fix typo"

This reverts commit d656aed599ee754646e16386ce5a4ab0117f2d6e.
Revert "mon: OSDMonitor: only thrash and propose if we are the leader"

This reverts commit 5eac38797d9eb5a59fcff1d81571cff7a2f10e66.
Revert "mon/OSDMonitor: send_to_waiting() in on_active()"

This reverts commit f06a124a7fa0717ef8c523408b31d814df57caca.

On peons, on_active() is only called when we *first* become active after an
election.  Only on the leader is it called after each commit/update.  This
makes this change cause other problems (broken subscriptions on peons, in
particular).  We possibly should fix that, but there is also a simpler fix
for the original problem we were trying to solve.

Signed-off-by: Sage Weil <sage@inktank.com>
mon/OSDMonitor: do not wait for readable in send_latest()

send_latest() checks for readable and, if untrue, will wait before sending
out the latest OSDMap.  This is completely unnecessary; I think it is a
hold-over from when we have independent paxos states.  An audit of all
callers confirms that everyone would be happy with whatever is committed,
even if we are in the process of committing an even newer version.

Effectively, everyone waits *above* this layer in the usual PaxosService
traps for whether we are readable or not.  This means that waiting_for_map
and send_to_waiting() go away entirely, which is nice.

This addresses, among other things: send_to_waiting() is called from
update_from_paxos(), which can be called when we are not readable due to
the paxos commit/finish timing changes in f1ce8d7c955a24 and
c711203c0d4b.  If no subsequent update happens, those waiters never get
their maps.

Instead, we send them immediately--we know they are committed and old
history is as good as future history.

Fixes: #5643
Signed-off-by: Sage Weil <sage@inktank.com>
mon: OSDMonitor: only thrash and propose if we are the leader

'thrash_map' is only set if we are the leader, so we would thrash and
propose the pending value if we are the leader.  However, we should keep
the 'is_leader()' check not only for clarity's sake (an unfamiliar reader
may cry OMGBUG, prompting to a patch much like this), but also because
we may lose a subsequent election and become a peon instead, while still
holding a 'thrash_map' value > 0 -- and we really don't want to propose
while being a peon.

[This is a rebased version of 5eac38797d9eb5a59fcff1d81571cff7a2f10e66,
complete with the typo fix in d656aed599ee754646e16386ce5a4ab0117f2d6e.]

Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
mon/OSDMonitor: discard failure waiters, info on shutdown

This would prevent a leak, if we didn't assert before that in the
failure_reporter_t dtor.

Signed-off-by: Sage Weil <sage@inktank.com>
mon/PaxosService: update on_active() docs to clarify calling rules

Signed-off-by: Sage Weil <sage@inktank.com>
Merge remote-tracking branch 'gh/wip-swift' into next

Reviewed-by: Greg Farnum <greg@inktank.com>