ais/s3: fix status codes for object and bucket deletes

[maglenno]

Return 204 for successful and idempotent object deletes, 204 for successful bucket deletes, and preserve 404 NoSuchBucket responses.

[Nahemah1022]

Can we distinguish a missing key from a missing remote bucket here? For example, an AWS bucket may still be in AIS BMD after being deleted directly from AWS. The backend then returns 404 ErrRemoteBckNotFound, but this branch converts it to 204 success. Please preserve 404 NoSuchBucket in that case and return 204 only when the bucket exists but the key is missing.

[alex-aizman]

yes, Tony is right. But there's a bigger, and different problem.

[alex-aizman]

Idempotency isn't the issue. Two different semantics are being conflated:

• "I deleted the object you asked for" vs
• "the object you asked to delete was not there."

AWS S3 happens to hide the difference and return 204 for both - that's an AWS choice, not a law, not a standard. In fact, it is an exception.

More to the point: AIStore is multi-backend, and S3 is one frontend of four. We have to stay consistent across backends and across AIStore itself:

• delete a missing object, ais:// bucket, no backend => 404
• ditto gs://, and likewise Azure / OCI => 404
• native ais object rm => 404

Now, as it happens, AWS is the outlier: its DeleteObject returns 204 with no error, so for AWS-backed buckets this branch never even fires.

Every other path - native ais:// and the non-AWS backends - returns an honest 404 for a missing key.

So the blanket 404=>204 doesn't "match S3" - it suppresses the not-found that everything except AWS already reports correctly, and makes the S3 frontend disagree with our own API.

So please drop the conversion. Let a missing object stay 404 / NoSuchKey, same as the native API and the other three supported Clouds.