Add peer fields to replace inlined Kubernetes API fields

[liggitt]

What type of PR is this?

/kind bug
/kind cleanup
/kind api-change

What this PR does / why we need it:

Three Kubernetes REST API types were being used as generic proto messages in the externalgrpc grpc API, but are not actually correct to use that way. Use of these types with protoreflect libraries was best-effort and not actually supported. These types remove the misleading ProtoMessage() marker method in 1.35, and will not be usable as generic proto message fields in Kubernetes v1.35.0.

To give a way for integrators to migrate, this adds peer podBytes and standard timestamp fields and sets them along with Pod/StartTime/EndTime. Readers can read from either field, preferring the podBytes and timestamp fields over the Kubernetes REST API fields. Before updating to Kubernetes 1.35 libraries, the Pod and metav1.Time fields will have to be removed.

See https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/5589-gogo-dependency#motivation and kubernetes/kubernetes#134256 for more details.

This PR:

• Adds a generation script so externalgrpc can be regenerated
• Adds peer fields to carry the same information as the corev1.Pod and metav1.Time fields, sets both when calling external endpoints, reads from both in the wrapper helper function.
• Marks the inlined Kubernetes REST API fields as deprecated.
• Adds a unit test that will catch if the Pod and metav1.Time types stop serializing via protoreflect libraries

Does this PR introduce a user-facing change?

The cluster-autoscaler externalgrpc PricingPodPriceRequest and PricingNodePriceRequest APIs deprecate the startTime, endTime, and pod fields, in favor of startTimestamp, endTimestamp, and podBytes fields.

[k8s-triage-robot]

This PR may require API review.

If so, when the changes are ready, complete the pre-review checklist and request an API review.

Status of requested reviews is tracked in the API Review project.

[jackfrancis]

Is this meant to suggest that writers on pre-1.35 k8s should set startTimestamp in addition to this field for best-practice future-proofing?

If so we might be able to word with more clarity (so that that "writers cannot" and "should set" in the same sentence isn't confusing) and I would also assume we plan to backport these changes to e.g., 1.31-1.34 in CA so that writers interacting w/ clusters on those versions have advance deprecation warning?

[dbonfigli]

It look goods to me, apart for some minor things:

• in wrapper.go we missed reading from the new fields in PricingNodePrice
• currently tests in externalgrpc_cloud_provider_test.go are using the now deprecated pod field, can you use the new pod_bytes also there?
• since you created the script to generate the proto, can you update the readme.md file to mention it and remove the old instructions?

So, to recap, as soon as someone update the cluster-autoscaler/cloudprovider/externalgrpc/protos/third_party/go.mod dependencies to use the 1.35 k8s libs, the externalgrpc_test.go will fail, and we need to remove the deprecated field from the proto and code, and then remove the test, right?

[liggitt]

Updated.

So, to recap, as soon as someone update the cluster-autoscaler/cloudprovider/externalgrpc/protos/third_party/go.mod dependencies to use the 1.35 k8s libs, the externalgrpc_test.go will fail, and we need to remove the deprecated field from the proto and code, and then remove the test, right?

Yes. That means we should cut a patch release with this change now to seed use of the new peer fields and encourage integrations to update and start making use of the new wrapper / proto / peer fields now so they can straddle 1.34/1.35 without disruption.

[dbonfigli]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dbonfigli, liggitt
Once this PR has been reviewed and has the lgtm label, please assign x13n for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• cluster-autoscaler/OWNERS

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

[dbonfigli]

I think we also need an approval from @x13n because there is a change in cluster-autoscaler/go.mod
/assign @x13n