Make Kubernetes API types available for import without the transitive dependencies of client-go

[wallrj]

It'd be useful if the generated Kubernetes API types were available in this or a separate repo.

They are currently in https://github.com/istio/client-go which imports
k8s.io/apimachinery v0.20.2 and k8s.io/client-go v0.20.2 and those transitive dependencies cause difficulties when your own project also imports different (maybe incompatible) versions of those libraries.

This would be similar to the separation between k8s.io/client-go and k8s.io/api

Describe alternatives you've considered

As a work around, we are considering copying the https://github.com/istio/client-go/tree/master/pkg/apis files into our project in https://github.com/jetstack/cert-manager/blob/eeedc1c9bb6d28d7dc44ed8a9d53bfd2672bb61c/pkg/issuer/acme/http/internal/istio/istio.go.

We might also try using the https://github.com/istio/tools/tree/master/cmd/kubetype-gen tool in our build scripts to automatically generate our own copies of the Kubernetes types.

[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[x] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[x] User Experience

Additional context

This stems from the following discussions:

• https://github.com/jetstack/cert-manager/pull/3724/files#r610062084
• Istio VirtualService for HTTP01 solving (rebased) cert-manager/cert-manager#3724 (comment)
• https://kubernetes.slack.com/archives/CDEQJ0Q8M/p1619190814489500

[wallrj]

@erikgb points out that cert-manager has the same issue: cert-manager/cert-manager#3381