osd/ReplicatedPG: handle promote that races with snap deletion

If we are promoting a clone and realize that the object is no longer
defined for any snaps, abort the copy and delete any temp object.

If the defined snaps have changed, make sure they are updated in memory
so that on promote completion the snapshot metadata is correct.

Signed-off-by: Sage Weil <sage@inktank.com>
osd: fix propagation of removed snaps to other tiers

When we update removed_snaps we do not update snap_seq.  Drop this broken
optimization.

Signed-off-by: Sage Weil <sage@inktank.com>
mon: debug propagate_snaps_to_tiers

Signed-off-by: Sage Weil <sage@inktank.com>
osd/Replicated: mark obc !exists on snap trim

Signed-off-by: Sage Weil <sage@inktank.com>
osd/ReplicatedPG: cleanly abort flush if the object no longer exists

If the object no longer exists (for example, because the snap trimmer just
killed it) clean up the flush state without trying to mark the object
clean.

Signed-off-by: Sage Weil <sage@inktank.com>
ceph_test_rados_api_tier: partial test for promote vs snap trim race

This reliably returns ENODEV due to the test at the finish of flush.  Not
because we are actually racing with trim, though: the trimmer doesn't run
at all.  I believe it captures the important property, though.  Namely:
we should not write a promoted object that is "behind" the snap trimmer's
progress.  The fact that we are in front of it (the trimmer hasn't started
yet) should not matter since the object is logically deleted anyway.

We probably want to make the OSD return ENODEV on read in the normal case
when you try to access a clone that is pending trimming.

Signed-off-by: Sage Weil <sage@inktank.com>
osd/ReplicatedPG: always return ENOENT on deleted snap

Previously, if a snap was deleted but the clone was there and we hadn't
trimmed it yet, we would still return the data.  Instead, return ENOENT
unconditionally (even it's not removed yet).  This makes the behavior from
the client perspective more predictable and conistent.

Signed-off-by: Sage Weil <sage@inktank.com>
osd/ReplicatedPG: update ObjectContext's object_info_t for new hit_set objects

We were fabricating an object_info_t correctly and writing it to disk, but
it was not reflected by the in-memory ObjectContext.  If something came
along quickly (like backfill) and tried to use it, the info would be
invalid.

Fix this by fabricating it in the obc and copying it to the new_obs for
the update.

Fixes: #7122
Signed-off-by: Sage Weil <sage@inktank.com>