Move From/ToCRI out of NRI so as to not leak the CRI versioning issues into NRI

[mikebrow]

In evaluating some CRI vendoring problems with kubernetes... @dmcgowan brought up the fact that we have leaked CRI over into NRI. This does not seem necessary. Let's move these From/To CRI linux resources functions over into the internal CRI implementation so as to not leak CRI vendoring/versioning issues.

https://github.com/containerd/nri/blob/main/pkg/api/resources.go#L84

https://github.com/containerd/containerd/blob/86d68096d2d033c0f161e869af8b69fbb05c6f7f/internal/cri/nri/nri_api_linux.go#L615

@klihub thoughts?

[klihub]

@mikebrow Okay, I'll take a look at moving these out from core NRI.

The only/original reason to have these CRI From/To conversion functions here is that they are used in both the containerd and cri-o integration bits, and I wanted to have a single implementation that lives together with the source/destination of the conversion.

An alternative to avoid the forced CRI dependency in core NRI, without duplicating code to both containerd and cri-o, would be to have a (separately versioned) NRI sub-package and put the conversion functions there. But I'm guessing that for these functions alone, it might not be worth the extra hassle.

[mikebrow]

nod.. was thinking the same..

can add cross link comments between the code in c/c and crio/crio so anyone adding a commit in the from/to cri would know to replicate it in the other implementation..

it does seem like we need a container runtime friendly cri-api project that is not tied directly to the k/k process of moving the golang min to the very latest version of golang with each version, e.g. one version of golang that shipped last month and still has serious bugs... also seems we could use a neutral go-cri repo for common utils that would be tied to the friendly cri-api

[mikebrow]

part 1 of 2(a/b) here #161

[klihub]

#161 has been merged, eliminating CRI dependencies from NRI.