pkg/api: add OptionalRepeatedString type

[marquiz]

[marquiz]

@klihub @chrishenzie @mikebrow

Pre-work for some of my upcoming work on managing the linux.intelRdt object of the runtime-spec. I decided to submit this one as a separate PR with the hopes of easier and more focused review.

I'm not sure if we need all the pointer's-pointer (or nil's-nil) stuff or would it be sufficient to return []string (instead of *[]string) from Get()

[klihub]

@klihub @chrishenzie @mikebrow

Pre-work for some of my upcoming work on managing the linux.intelRdt object of the runtime-spec. I decided to submit this one as a separate PR with the hopes of easier and more focused review.

I'm not sure if we need all the pointer's-pointer (or nil's-nil) stuff or would it be sufficient to return []string (instead of *[]string) from Get()

@marquiz. This is I think the only part I was wondering about. But you will probably get a much better understanding about what makes sense for Get() and what alternatives make sense for the constructor once you have written some more code exercising this. Then there are two options. Either start with the minimal set your code needs, or with what you guesstimate to be potentially necessary. But this already LGTM as such.

[chrishenzie]

+1 to @klihub 's comment -- would it be possible to add your intended use case as a separate commit in this PR so we can take a look how it's being used? I'd prefer to review that vs. merge now and have to make subsequent changes later

[marquiz]

Rebased, marked ready-for-review. @klihub @mikebrow @chrishenzie

[mikebrow]

attempt at adding clarity around the ensure clone comment I made.. https://github.com/containerd/nri/pull/212#discussion_r2557259247

[chrishenzie]

It looks like proto3 has a built-in optional keyword, but doesn't support optional repeated syntax.

Is the goal of this wrapper type to distinguish between a nil (unset) list and an empty list? If that distinction isn't critical for the intelRdt use case, could we simplify the API by using a standard repeated string field and treating an empty list as unset?

This probably is beyond the scope of this PR, but I'm just curious about this API choice that was made

[marquiz]

Is the goal of this wrapper type to distinguish between a nil (unset) list and an empty list?

Exactly. There are similar "optional" wrappers for other types. This follows suite

If that distinction isn't critical for the intelRdt use case, could we simplify the API by using a standard repeated string field and treating an empty list as unset?

For now, it's not critical. But I want to be able to make the difference whether the list was specified or not. Make sure that we're not caught off guard if the empty list get's a special meaning in the runtime-spec in the future.