lib: remove deprecated APIs and implicit resource creation

[mtjhrc]

This PR is a preparatory cleanup before the full 2.0 API (#634).

Depends on
Depends on: #673 "Replace hardcoded init.krun with generic virtual file overlay"

New functionality introduced (replacing old way of doing this)

• krun_set_oci_config_json(ctx, json) — set init config from OCI container-spec JSON (user shall no longer write it to disk)
• krun_inject_init(ctx, fs_tag) — explicitly injects the init binary and json config for the init into the guest

Deprecated functions removed

• krun_set_log_level → krun_init_log
• krun_set_root_disk → krun_add_disk3
• krun_set_data_disk → krun_add_disk3
• krun_set_passt_fd → krun_add_net_unixstream
• krun_set_gvproxy_path → krun_add_net_unixgram
• krun_set_net_mac → mac parameter on krun_add_net_*
• krun_set_mapped_volumes — was already returning -EINVAL
• krun_set_console_output → krun_add_virtio_console_default
• krun_get_default_init → krun_inject_init

Old numbered API variants removed

• krun_add_disk, krun_add_disk2 → krun_add_disk3
• krun_add_virtiofs, krun_add_virtiofs2 → krun_add_virtiofs3
• krun_add_vsock_port → krun_add_vsock_port2
• krun_set_gpu_options → krun_set_gpu_options2

Implicit resource creation removed

• krun_disable_implicit_init + implicit init injection → krun_inject_init(ctx, fs_tag)
• krun_disable_implicit_console + implicit console → krun_add_virtio_console_default(ctx, in, out, err)
• krun_disable_implicit_vsock + implicit vsock with TSI heuristics → krun_add_vsock(ctx, tsi_features)

Init config delivery change

krun_set_exec/krun_set_env/krun_set_workdir/krun_set_rlimits no longer format config into kernel cmdline env vars (KRUN_INIT=, KRUN_WORKDIR=, -- args). Instead, they use newly introduced InitConfig /.krun_config.json on virtiofs.

The kernel cmdline no longer carries:

• KRUN_INIT=...
• KRUN_WORKDIR=...
• KRUN_RLIMITS=... (now injected as an env var in the JSON Env array — see FIXME in code)
• env vars
• -- args epilog

Only KRUN_BLOCK_ROOT_DEVICE (+ fstype/options) remains on the cmdline when a block root is configured.

Init side follow-up: The C init (init/init.c) still supports both the cmdline and JSON paths. Eventually (maybe as part of #670), the legacy cmdline parsing can be dropped from init since libkrun will no longer use it.

[ggoodman]

There's an interesting API design challenge here where krun_set_exec and some other methods are coupled to the specific init implementation. In other words, there's a contract with a pluggable init.

Another way to do this might be to explore passing the init-specific config when choosing the init binary. It's subtle but it makes it clear that the two things are coupled.

[mtjhrc]

There's an interesting API design challenge here where krun_set_exec and some other methods are coupled to the specific init implementation. In other words, there's a contract with a pluggable init.

This is not the final design, this is only the first step in untangling this, I'll decouple this more. The main motivation for this was to get rid of the buggy argv forwarding via the kernel command line and unify everything around our json config.

Currently the krun_set_exec and the other functions just forward to the init config builder methods defined in blob-init (this way, the output format produced by the builder and the format expected by the init binary stay in sync). In the future, you'll call the builder methods directly, but exposing them cleanly right now was complicated (you'd need something like a separate handle for the builder; a Rust/C bindings generator I'm working on should help with this).

If you wanted to use a different init, its configuration will be completely transparent to libkrun. I think the contract will simply be that you provide some virtual files (libkrun won't care if they are executables or configs or whatever) and add the appropriate kernel arguments (e.g. like set the init= kernel arg).