ReplicatedPG: do not create snapdir on head eviction

Head eviction implies that no clones are present.  Also, add
an exists flag to SnapSetContext in order prevent an ssc from
a recent eviction from preventing a snap read from activating
the promotion machinery.

Fixes: #7858
Signed-off-by: Samuel Just <sam.just@inktank.com>
ReplicatedPG::do_op: use get_object_context for list-snaps

find_object_context provides some niceties which we don't need since we know
the oid of the clones.  Problematically, it also return ENOENT if the snap
requested happens to have been removed.  Even in such a case, the clone may
well still exist for other snaps.  Rather than modify find_object_context to
avoid this situation for this caller, we'll simply do it inline in do_op.

Fixes: #7858
Signed-off-by: Samuel Just <sam.just@inktank.com>
ReplicatedPG,rados: add CEPH_OSD_[COPY_FROM]_IGNORE_RMED_SNAP

When attempting to promote a particular clone, we need to be able to able to
handle the posibility that the snap we are using to specify the clone may have
been removed.  Also, the cloneid used by the backing pool may not be the same
as the clone id used in the cache pool in the event that the cache pool's
cloneid has been removed before the clone in question has been flushed.  Thus,
we will promote using a snap which currently maps to the clone we want.  The
backend will do 1 of 2 things:
1) If the clone still exists, our requested snap will map to that clone
2) If the clone has been trimmed, we may end up reading from another
subsequent object.
We handle case 2) by, in finish_promote, verifying that our current pool info
indicates that the clone should still exist.

Fixes: #7858
Signed-off-by: Samuel Just <sam.just@inktank.com>