OpenAPI v3 support

[Arnavion]

https://github.com/kubernetes/kubernetes/blob/9d278e622427d307d50c1c2440b556005e2f8769/CHANGELOG/CHANGELOG-1.24.md#openapi-v3

Kubernetes 1.24 offers beta support for publishing its APIs in the OpenAPI v3 format.

Compare with the v2 schema to see if anything is documented more precisely, eg using oneOf etc.

---

https://github.com/kubernetes/kubernetes/tree/dfee09a27da7f409c46c37e0b93fe067eafa4ae9/api/openapi-spec/v3

(Refs: https://swagger.io/specification/ | https://datatracker.ietf.org/doc/html/draft-wright-json-schema-validation-00 )

The v3 schema doesn't seem to have much that's different from the v2 schema, let alone better.

• oneOf is only used for io.k8s.apimachinery.pkg.api.resource.Quantity and io.k8s.apimachinery.pkg.util.intstr.IntOrString. The latter already has custom codegen. The former advertises itself as "oneOf": [{ "type": "string" }, { "type": "number" }], similar to IntOrString, but its documentation indicates one should always use the string form anyway, so the current codegen (newtype around String) might actually be preferable.

• Hacks like JSONSchemaPropsOrArray are still present, and still need to be treated in the same way.

• "allOf" is only used with a single element in each use site, so it's not providing any new info, just associating the field / parameter with its type.

• Neither of the two extent "upstream bugs" have been fixed. GVK still references NodeProxyOptions etc that don't exist as definitions. connectCoreV1GetNamespacedPodExec still annotates its command querystring parameter as a single string.

• List operations still include watch operation parameters, so they still need to be split apart.

• Any other validations that restrict values - "enum", the various "min" and "max", "pattern" etc - are not used anywhere.

• The schema is split into ~50 files, two per API group, and they all reference types from each other. This means a) lots of files would need to be downloaded instead of one swagger.json, and b) a large portion of each would be redundant and need to be thrown away. Eg io.k8s.apimachinery.pkg.apis.meta.v1.ObjectMeta is defined identically in 24 files.

So at this point the only reason to implement support for this would appear to be users wanting to run the generator against their own clusters.