feat: expose a Rust API

[appcypher]

Currently, libkrun is built in Rust but only offers a C interface (via include/libkrun.h), and it doesn’t provide very helpful error messages. This can make troubleshooting a bit of a headache.

It would be great to turn libkrun into a proper Rust crate. By doing so, we could take full advantage of Rust’s powerful type system and the intuitive Result type for error handling, making life easier for everyone integrating libkrun into their projects.

[mtjhrc]

Sure this could be nice, but could you clarify how would you like to use it? libkrun is currently a dynamically linked library and Rust doesn't have a stable ABI.

• Do you want a Rust bindings crate built on top of the C API, which would allow you to consume libkrun as a dynamic library, but you would use nicer Rust types, such as Result<>? Keep in mind that this wouldn't really improve the detail of errors, just the ease of handling them. At some point we plan to have a v2 of the C API, but here are no specific plans yet - we might also have more detailed error messages. I have kind of started going in this direction, because I needed it when adding tests (https://github.com/containers/libkrun/pull/258/) here: https://github.com/containers/libkrun/pull/258/commits/5f063e02ba3c75474bd3bdab43b66c92de0af6dc. We might publish this on crates.io. For easy error handling I am just using a macro, but you could write higher level bindings on top of these ones.

• Do you want to use this as a normal Rust crate (statically linked)? In principle I wouldn't be against it, but in this case, we should really build the C API on top of the new Rust API (so we have a clear public API boundary).

[appcypher]

Yes. I'm referring to using libkrun statically linked in another Rust project.

Option 2 is what I would imagine it to be like.