[2.2] Handle []byte envvar value

[liggitt]

Part of recovering from a regression in the ability of v0.34.0+ cri-api being able to transmit binary non-utf8 envvar values

xref

• CreateContainerError when secret env var contains invalid UTF-8 bytes (gRPC strict validation regression) kubernetes/kubernetes#139132
• Restore ability to plumb binary data through envvar values kubernetes/kubernetes#139168 (comment)

cc @mikebrow @samuelkarp

This updates to a cri-api patch release that switched the proto type of the envvar value field from string to bytes, and adds a []byte → go string cast in the spot that handles this CRI field.

[liggitt]

(the vendor verification task of the "Project Checks" CI is expected to fail since this is monkeying with a vendored cri-api file ... other compile / test checks should succeed)

[thaJeztah]

Wondering; has the same case also been tested on other runtimes? The "portable character set" would still be the recommended approach (depending on anything outside it would always be somewhat undefined behavior)

[liggitt]

Wondering; has the same case also been tested on other runtimes? The "portable character set" would still be the recommended approach (depending on anything outside it would always be somewhat undefined behavior)

Totally agree, this is mostly trying not to regress on an upgrade unintentionally due to plumbing errors. I think it would be fair game for a particular runtime to have rejected data outside a specified character set from day 1... doing so unintentionally and unannounced is ... less ok (this was caused by a proto encoder/decoder change in cri-api in Kubernetes 1.34 ... trying to recover from that now in as minimal a way as possible)

[thaJeztah]

Oh! I just realized I commented on a backport, not the one from main. 🙈

[liggitt]

yeah, sorry for the context-free PR... summary and lots of discussion linked from kubernetes/kubernetes#139168 (comment)

[liggitt]

I'll update with picks from the final commits once the main PR merges