What would you like to be added?

We have environments that hit the etcd db size quota and etcd cluster arms the no space alarm. Kubernetes compaction code needs to do a put request before running compaction. As a result, when etcd cluster is under no space, the compaction cannot go thru. This request is to find a way to allow compaction as run by kubernetes api-server to go thru when etcd is under no space alarm.
Ref to the put request described above - https://github.com/kubernetes/kubernetes/blob/b60176972182bc2a459e019bc039dfcffa2ff868/staging/src/k8s.io/apiserver/pkg/storage/etcd3/compact.go#L137

Related issues -
kubernetes/kubernetes#94029 - this issue mentions that this can be an etcd feature where etcd distinguishes between compaction key and user key.

Related issue from google search - https://bugzilla.redhat.com/show_bug.cgi?id=1984563

Alternatively, etcd might be able to facilitate extended compaction api that does the put internally and can bypass no space.

Why is this needed?

we have environments that run into no space alarm and we would like to enable self-service for recovering back from the alarm.