Add benchmark test for parsing openapi in protobuf format

[mengqiy]

The following is the benchmark results:

goos: darwin
goarch: amd64
pkg: sigs.k8s.io/kustomize/kyaml/openapi
cpu: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
BenchmarkSwaggerUnmarshalJSON
BenchmarkSwaggerUnmarshalJSON-16      	       2	 609778913 ns/op
BenchmarkOpenAPIV2ParseDocument
BenchmarkOpenAPIV2ParseDocument-16    	       4	 260217958 ns/op
BenchmarkProtoUnmarshal
BenchmarkProtoUnmarshal-16            	      79	  15062865 ns/op

If we switch to github.com/googleapis/gnostic/openapiv2, but still parsing JSON, we can get 2.3X faster.
If we switch to github.com/googleapis/gnostic/openapiv2 and use proto completely, we can get 40.5X faster.

If switching to github.com/googleapis/gnostic/openapiv2, we will need to make some big change to kyaml/openapi.

Related issue: #3670

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mengqiy

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• kyaml/OWNERS [mengqiy]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mengqiy]

/cc @droot @natasha41575 @KnVerey

[natasha41575]

If we switch to github.com/googleapis/gnostic/openapiv2, but still parsing JSON, we can get 2.3X faster.
If we switch to github.com/googleapis/gnostic/openapiv2 and use proto completely, we can get 40.5X faster.

IMO we should start with still parsing JSON. Because users can provide their current openapi schema in JSON we will need to continue to support JSON parsing regardless. I can work on this.

Once that is working, we can take a look at using proto. While doing so we should make sure that users can still provide additional schema in JSON. We also should allow users to provide their input schema in proto form. We currently accept both JSON and yaml, so supporting a third type of format should be fine.

How did you retrieve the proto format of the openapi data? I'm thinking that if we start parsing proto schemas, we should support a kustomize openapi fetch --proto option, analogous to the kustomize openapi fetch --json and kustomize openapi fetch --yaml we currently have.

[natasha41575]

Also, I did a check to see if introducing github.com/googleapis/gnostic will be a problem with kubectl integration. It looks like upstream kubernetes already has this dependency, so it should be fine.

[yuwenma]

This looks great! (Could you fix the presubmit?)

[mengqiy]

To retrieve the openapi in proto, see: https://kubernetes.io/docs/concepts/overview/kubernetes-api/#openapi-v2

For your convenience, I use the following:

To retrieve it from a GKE cluster using gcloud:
curl -k -H "Accept: application/com.github.proto-openapi.spec.v2@v1.0+protobuf" -H "Authorization: Bearer $(gcloud auth print-access-token)" https://<your-server-ip>/openapi/v2 > openapi.pb

To retrieve it using kubectl + curl:
Run kubectl proxy first, then run
curl -k -H "Accept: application/com.github.proto-openapi.spec.v2@v1.0+protobuf" http://localhost:8001/openapi/v2 > openapi.pb

I can't use kubectl get --raw to do achieve it, since it doesn't allow me to set the header.

[mengqiy]

We should support parsing both JSON and proto. Our baked-in openapi schema should be in proto, since it can be much faster. And users are more likely to provide JSON.
As we discussed earlier, we should allow user to provide a partial openapi schema that will be merged with the built-in schema.

[mengqiy]

I reverted the change in go.mod that upgrade the kube-openapi dependency. It should be passing this time.

[natasha41575]

Related: #3248

/lgtm