librbd: avoid data corruption on flatten when object map is inconsistent

librbd: avoid data corruption on flatten when object map is inconsistent

By making flatten skip copyup in case the object is marked
OBJECT_EXISTS or OBJECT_EXISTS_CLEAN, commit 40af4f87b64f ("librbd:
flatten operation should use object map") introduced a critical
regression.  If the object map becomes inconsistent (e.g. because
flatten gets interrupted by killing "rbd flatten" process or a client
running on the clone crashes after updating the object map but before
writing to the image), the following attempt to flatten would corrupt
the clone if the copyup is actually still needed.

By design, it's impossible to tell whether the object is "known to
exist" based on the object map -- only telling whether the object is
"known to NOT exist" is possible (i.e. only OBJECT_NONEXISTENT state
is reliable).  Negating OBJECT_NONEXISTENT tells that the object "may
exist", not that the object is "known to exist".  This is reflected in
the name of object_may_exist() helper that was introduced together with
the object map implementation.  Something like object_may_not_exist()
simply can't be constructed given the rest of librbd.

This effectively reverts commits 4c86bccf07b8 ("librbd: add
object_may_not_exist helper") and 40af4f87b64f ("librbd: flatten
operation should use object map").

Fixes: https://tracker.ceph.com/issues/68998
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 97ed3fced13dd48520ec9c165537ff0bbc7cbb64)