mon/OSDMonitor: allow osdmap trimming to be forced via a config option

In certain cases the admin may know that it is safe to trim old osdmaps but
a bug or other issue is preventing the Monitor from deciding on its own.

Signed-off-by: Sage Weil <sage@inktank.com>
osd: report pg stats to mon at least every N (=500) epochs

The mon needs a moderately accurate last_epoch_clean value in order to trim
old osdmaps.  To prevent a PG that hasn't peered or received IO in forever
from preventing this, send pg stats at some minimum frequency.  This will
increase the pg stat report workload for the mon over an idle pool, but
should be no worse that a cluster that is getting actual IO and sees these
updates from normal stat updates.

This makes the reported update a bit more aggressive/useful in that the epoch
is the last map epoch processed by this PG and not just one that is >= the
currenting interval.  Note that the semantics of this field are pretty useless
at this point.

See #5519

Signed-off-by: Sage Weil <sage@inktank.com>
mon: be smarter about calculating last_epoch_clean lower bound

We need to take PGs whose mapping has not changed in a long time into
account.  For them, the pg state will indicate it was clean at the time of
the report, in which case we can use that as a lower-bound on their actual
latest epoch clean.  If they are not currently clean (at report time), use
the last_epoch_clean value.

Fixes: #5519
Signed-off-by: Sage Weil <sage@inktank.com>
osd: change pg_stat_t::reported from eversion_t to a pair of fields

This rarely represents an actual eversion_t as the epoch and seq values are
bumped semi-independently to ensure it is always unique.  Break it into
two separate fields to avoid confusion.

Drop now-unused and slightly curious inc() method.

Signed-off-by: Sage Weil <sage@inktank.com>
Merge branch 'wip-mon-osdmap-trim'

Reviewed-by: Samuel Just <sam.just@inktank.com>