More consistent and safe use of exceptions in do_remove()

[qc00]

An extension of #447

Currently, do_remove_impl in S3 (and MongoStorage::do_remove) swallows all errors in the batching loop and reports the keys in the erroring requests in a KeyNotFoundException at the end.

This has multiple issues:

1. If AWS returned THROTTLING or SLOW_DOWN, we should sleep. Otherwise, a subsequent request that might otherwise work will fail
2. Lumping all errors into one exception may mask exception types that the caller might want to handle, like permission exception
3. S3 does not error on deleting non-exist objects, so KeyNotFoundException is very misleading
4. Due to naive batch logic, the exception might contain keys that have been deleted

For example, the second issue can fool the StorageLock::unlock() logic into believing the lock key has been removed, leading to a race condition or deadlock.

I think it's more reliable to:

• detect keys that really don't exist in the storage, and continue to report those in a KeyNotFoundException at the end
• for any other kind of errors, throw a different exception immediately

In the latter case, it's the caller's responsibility to retry immediately or leave the data in a sound state for the user to retry.

[qc00]

A similar issue exists in do_key_exists[_impl]:

Currently, the function returns false for any exception, so any logic using this function for safety may mistake a transient server/network issue for a key not existing.