PG: ignore non MISSING pg query in ReplicaActive

1) Replica sends notify
2) Prior to processing notify, primary queues query to replica
3) Primary processes notify and activates sending MOSDPGLog
to replica.
4) Primary does do_notifies at end of process_peering_events
and sends to Query.
5) Replica sees MOSDPGLog and activates
6) Replica sees Query and asserts.

In the above case, the Replica should simply ignore the old
Query.

Fixes: #4050
Backport: bobtail
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
OSD: expand_pg_num after pg removes

Otherwise:
1) expand_pg_num removes a splitting pg entry
2) peering thread grabs pg lock and starts split
3) OSD::consume_map grabs pg lock and starts removal

At step 2), we run afoul of the assert(is_splitting)
check in split_pgs.  This way, the would be splitting
pg is marked as removed prior to the splitting state
being updated.

Backport: bobtail
Fixes: #4449
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
FileJournal: queue_pos \in [get_top(), header.max_size)

If queue_pos == header.max_size when we create the entry
header magic, the entry will be rejected at get_top() on
replay.

Fixes: #4436
Backport: bobtail
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
FileStore: add more debugging for remove and split

Signed-off-by: Samuel Just <sam.just@inktank.com>
FileJournal: add committed_up_to to header

header_t::committed_up_to provides a lower bound for safetly committed
journal entries.  If read_entry fails prior to committed_up_to, we
know we have a corrupt jorunal entry.  Furthermore, if
journal_write_header_frequency is not 0, we will write out the
journal header once every journal_write_header_frequency
journal writes.

Signed-off-by: Samuel Just <sam.just@inktank.com>
FileJournal::wrap_read_bl: convert arguments to explicit in/out arguments

Signed-off-by: Samuel Just <sam.just@inktank.com>
FileJournal,Journal: detect some corrupt journal scenarios

When the checksum or footer are invalid, we will now try to
look at the next entry.  If we find a valid entry, it is likely
that the journal is corrupt.

Signed-off-by: Samuel Just <sam.just@inktank.com>
FileJournal: add testing methods to corrupt entries

Signed-off-by: Samuel Just <sam.just@inktank.com>
test_filejournal: add tests for footer, header, payload corruption

Signed-off-by: Samuel Just <sam.just@inktank.com>
Merge branch 'next'
Merge branch 'wip_4196'

Reviewed-by: Sage Weil <sage@inktank.com>
Fixes: #4196