Implement behaviors for OCI URI

[jgchn]

Is your feature request related to a problem? Please describe.
Currently, the oci://... uri behavior is not supported.

Describe the solution approach you'd like
Consider the following sub-fields in an MSVC

 modelArtifacts:
    # Example: oci://quay.io/crio/artifact:v1/path/to/model
    uri: "oci://<complete image identifier including tag>::/path/to/model"
    # OCIs can have pull secrets, not supported ATM
    # authSecretName(s): mytokens
containers:
    - name: vllm
      args:
      # {{ .CompleteModelPath }} = mountPath + /path/to/model
      - "{{ .CompleteModelPath }}"
      mountModelVolume: true

The pod-spec generated out of msvc should look like this.

containers:
    - name: vllm
      args:
      - "{{ .CompleteModelPath }}"
      volumeMounts:
      - mountPath: /model-cache # this must always be the model-storage mountPath for oci:// URIs.
         name: model-storage
    volumes:
    - name: model-storage
      image:
        reference: <complete image identifier including tag>

---

Note that the msvc resource specs (of which the above is a snippet) get mergo merged as usual into the baseconfig specs.

---

Behind the scenes:

The .mountModelVolume: true should induce the following behavior for the msvc generated deployment specs (this is even before the baseconfig merges).

1. Creates a volume (model-storage) in the podSpec to pull from an image reference
2. Adds volumeMounts the container where .mountModelVolume is true
3. Exports {{ .CompleteModelPath }} as mountPath (hardcoded to oci-dir) + path/to/model (from URI)

[sriumcp]

Considering https://kubernetes.io/blog/2024/08/16/kubernetes-1-31-image-volume-source/, lets also support a couple of other options.

1. pullPolicy (can be part of modelArtifacts)
2. Creation of service account for PD pods along with the right pull secret (the authSecretName should be used as the pull secret for PD service accounts).

Note: PD pods still doesn't require role bindings.

[jgchn]

@spartha Can users supply multiple authSecretName for PD pull policy? I believe we support list of PD pull secrets in our root command.

[sriumcp]

Hmmm.. maybe we should leave authSecretName for auth purposes (i.e., it doesn't come into play for OCI at all).

---

Since there's already a mechanism to provide pull secrets to pd images, we just leverage that for OCI images as well.

This means, the PD pull secrets for OCI images are known and supplied during controller startup time... we can start there, and reassess if there's a need to support pull secrets inside msvc in the future.