Create long-term plan for openapi, crds, and configurations fields

[natasha41575]

Umbrella issue for handling openapi, crds, and configurations long-term. Related issues:

• Reconcile crds and openapi fields #3944
• Consider deprecating configurations field #3945
• Allow custom merge keys? #5110

[natasha41575]

The idea here is that we have several fields, configurations, openapi, and crds that all require the user to provide input about custom resources.

We should have a plan to consolidate these fields into a better, unified design. It doesn't need to be consolidated into a single field, but it should be more coherent and sensical.

The first action item on this issue to do some research to fully understand what the various fields would do. Leaving a comment here on your understanding will be helpful for future context. The step after that would be to put together a mini KEP with a design of what this should eventually look like, which should take into consideration the ease of migration for current users of the existing fields.

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted