Failed delete must return a ResponseRange instead

[neoaggelos]

Summary

Follow-up PR for #145 to account for delete operations that do not succeed.

For more context see:

• https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/etcd3/store.go#L337-L338
• Slack discussion with sig-api-machinery https://kubernetes.slack.com/archives/C0EG7JC6T/p1668796684479099. The decision is that it's up to the etcd3 implementation to return a valid response, and on failed deletes this means return a ResponseRange instead (as it falls-through to a simple get response).

@brandond Apologies for the initial PR being incomplete, I'm testing this as I go as well :) With this change I don't see anything blowing up, so things should be fine now.

[brandond]

Right, this would probably be harder to get wrong if we actually looked at the transaction operation that the apiserver is trying to do, instead of assuming it and hardcoding the responses. Unfortunately, making assumptions is a lot easier than implementing the full transaction syntax.

This says "if the revision is equal, then delete, otherwise get": https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/etcd3/store.go#L326-L332