lib: remove deprecated APIs and implicit resource creation

[mtjhrc]

This PR removes deprecated and superseded API functions, preparing for the 2.0 API (#634).

The init-blob integration (krun_inject_init, krun_set_oci_config_json, init config delivery changes) has been split into a separate PR built on top of this one.

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_root → krun_add_virtiofs3 with "/dev/root" tag
• krun_set_console_output → krun_add_virtio_console_default

Implicit resource creation removed

• krun_disable_implicit_console → this is now the default behavior
• krun_disable_implicit_vsock → this is now the default behavior

Tests and examples have been updated to use the current API equivalents.

[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).

[mtjhrc]

Note that I've removed the init configuration changes from this PR and moved them into:

• WIP: Move krun-init to a separate .so library (similar to libkrunfw) #706

That PR goes further in the init/libkrun decoupling as discussed above.