mon/MonitorDBStore: expose get_chunk_tx()

Allow users get the transaction unencoded.

Signed-off-by: Sage Weil <sage@inktank.com>
mon: include any new paxos commits in each sync CHUNK message

We already take note of the paxos version when we begin the sync.  As
sync progresses and there are new paxos commits/txns, include those
and update last_committed, so that when sync completes we will have
a full view of everything that happened during sync.

Note that this does not introduce any compatibility change.  This change
*only* affects the provider.  The key difference is that at the end
of the sync, the provide will set version to the latest version, and
not the version from the start of the sync (as was done previously).

Signed-off-by: Sage Weil <sage@inktank.com>
mon/Paxos: configure minimum paxos txns separately

We were using paxos_max_join_drift to control the minimum number of
paxos transactions to keep around.  Instead, make this explicit, and
separate from the join drift.

Signed-off-by: Sage Weil <sage@inktank.com>
mon/Paxos: increase paxos max join drift

A value of 10 is too aggressive for large, long-running syncs. 100 is
about 2 minutes of activity at most, which should be a more forgiving
buffer.

Signed-off-by: Sage Weil <sage@inktank.com>
mon: uninline _trim_enable and Paxos::trim_{enable,disable} so we can debug them

Signed-off-by: Sage Weil <sage@inktank.com>
mon/Paxos: fix sync restart

If we have a sync going, and an election intervenes, the client will
try to continue by sending a new start_chunks request.  In order to
ensure that we get all of the paxos commits from our original starting
point (and thus properly update the keys from which they started),
only pay attention if they *also* send their current last_committed
version.  Otherwise, start them at the beginning.

Signed-off-by: Sage Weil <sage@inktank.com>
Merge remote-tracking branch 'gh/cuttlefish' into wip-mon-sync-2
Merge remote-tracking branch 'gh/wip-mon-sync-2' into cuttlefish

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