ReplicatedPG: start_flush: use filtered snapset

ReplicatedPG: start_flush: use filtered snapset

Otherwise, we might send our deletes based on deleted snaps.  This is
problematic since we may have trimmed the clones to which those snaps
belong, causing us to send them at an earlier snap than we used before.

The specific situation was

78:[78, 70, 63, 5a, 58, 57]:[64(63), 58(58, 57)]

with 58 already clean.  To flush 64, we send:

delete@58
delete@59
copyfrom@62

Then, snap 63 is trimmed leaving us with a snapset of:

78:[78, 70, 63, 5a, 58, 57]:[58(58, 57)]

since trim_object doesn't filter the head object snapset snaps.  This
isn't really a bug since in general all snapset users must be aware
that there may be trimmed snaps in snapset::snaps.  However, here
it becomes a problem when we go to flush head:

delete@58 -- ignored due to snapc
delete@59 -- ignored due to snapc
copyfrom@78 -- not ignored

The base pool head is at snap seq 62, so it clones that value into
clone 78(78, 70) instead of forgetting it.  What should have happened
is that we should have based our flushes on filtered snapset:

78:[78, 70, 58, 57]:[58(58, 57)]

Causing us to instead send:

delete@58 -- ignored due to snapc
delete@69 -- not ignored, causes no clone to be made
copyfrom@78 -- not ignored, updates head such that a subsequent clone
will leave 70 out of the clone snaps vector.

Fixes: 11787
Signed-off-by: Samuel Just <sjust@redhat.com>
(cherry picked from commit 6051e255ac062985ada1989edb7f23cd750915e2)