Ability to call specific modules in wasmtime no longer works

[jsturtevant]

After switching to youki in #131, the ability to pass module names via the entry point no longer works. See a repo in https://github.com/containerd/runwasi/compare/main...jsturtevant:runwasi:specific-modules?expand=1

running 1 test
[2023-07-21T23:24:52Z ERROR libcontainer::process::container_init_process] executable ./hello.wat#foo for container process not found in PATH
[2023-07-21T23:24:52Z ERROR libcontainer::process::container_intermediate_process] failed to initialize container process: invalid executable: ./hello.wat#foo

Do we want to re-enable this? It is due to youki doing runtime checks when starting the container: https://github.com/containers/youki/blob/c3559e4a0aff56d63bcda80f35e7cf0b58ccacbe/crates/libcontainer/src/process/container_init_process.rs#L106-L117

[jsturtevant]

pr that originally introduce this: https://github.com/containerd/runwasi/pull/102/files

[Mossaka]

I've raised this issue discussion first in the Slack chat. The following is just a repeat of what I said.

I went to the OCI Image Spec to checkout the specification of the entrypoints and it says they are

A list of arguments to use as the command to execute when the container starts. These values act as defaults and may be 
replaced by an entrypoint specified when creating a container.

My interpretation is that entrypoints are not strictly defined as executable binaries. In the case with runwasi, they could be functions in a Wasm module like ./hello.wat#foo. Thus, could we loose the requirement in libcontainer for verifying entrypoints? Specifically, could we make verify_binary optional?

[jsturtevant]

This was fixed by #297 and each of the shims now has tests covering this after #306