cls/refcount: ENOENT when put on non-existent object

If we get ENOENT, do not that that to mean an implicit reference count of
1.  That means that if you put a non-existent object, we should get
ENOENT instead of doing a useless delete on the OSD.

Note that this changes the get behavior slightly, too: doing a get on a
non-existent object will now fail with ENOENT instead of implicitly
creating it.

Stumbled across this from #10262.

Signed-off-by: Sage Weil <sage@redhat.com>
osd: handle no-op write with snapshot case

If we have a transaction that does something to the object but it !exists
both before and after, we will continue through the write path.  If the
snapdir object already exists, and we try to create it again, we will
leak a snapdir obc and lock and later crash on an assert when the obc
is destroyed:

0> 2014-12-06 01:49:51.750163 7f08d6ade700 -1 osd/osd_types.h: In function 'ObjectContext::~ObjectContext()' thread 7f08d6ade700 time 2014-12-06 01:49:51.605411
osd/osd_types.h: 2944: FAILED assert(rwstate.empty())

Fix is to not recreated the snapdir if it already exists.

Fixes: #10262
Signed-off-by: Sage Weil <sage@redhat.com>
Merge pull request #3183 from ceph/wip-10262

osd: fix handling of create+delete transaction

Reviewed-by: Samuel Just <sjust@redhat.com>