1. Proposed title of this feature request
[openshift-apiserver] - No pruning/clean of audit and revision-status in openshift-apiserver

2. What is the nature and description of the request?
While in openshift-kube-apiserver revision-pruner seems to happen, it seems that in openshift-apiserver namespace similar pruning/cleanup functionality is missing, causing number of ConfigMaps to pile up. It's also not clear whether those ConfigMap revisions are still required or could be removed as it would reduce amount of objects required to be managed by the platform.

> $ oc get cm -A | grep revision-status | cut -d ' ' -f1 | sort -h | uniq -c | sort -h
>       5 openshift-etcd
>       5 openshift-kube-apiserver
>       5 openshift-kube-controller-manager
>       6 openshift-kube-scheduler
>       8 openshift-oauth-apiserver
>      23 openshift-apiserver

> $ oc get cm -A | grep audit | cut -d ' ' -f1 | sort -h | uniq -c | sort -h
>       1 openshift-monitoring
>       6 openshift-kube-apiserver
>       9 openshift-oauth-apiserver
>      24 openshift-apiserver

The above output is from a OpenShift Container Platform 4 - Cluster that has been running for 5 days. Looking at the numbers of ConfigMaps now, just consider the number shown when the OpenShift Container Platform 4 - Cluster would run for 1 or 2 year. It would host a massive amount of ConfigMaps which are likely not required but will need to be managed by the platform and potentially required to be re-encrypted every 7 days (which seems unnecessary).

3. Why does the customer need this? (List the business requirements here)
Missing proper clean-up of revision related objects can cause unnecessary growth of etcd database and therefore impact on overall performance and stability. As other components are implementing proper revision pruning it's requested that openshift-apiserver is doing the same to keep the environment clean and limit it to the objects really required.

4. List any affected packages or components.
openshift-apiserver