Feat/allow docker private images

[Leay15]

This pull request builds on #310 by enabling pulling private images, adds port configuration as a complement to #349, and introduces fractional CPU support (Linux only, due to the cgroups v2 API).

It introduces the following improvements:

• Add port ranges for sandbox usage (useful when running the msb server with Docker port mappings).
• Enhance registry authentication support for image operations.
• Support fractional CPU values in sandbox and build configurations.
• Add new CLI commands for registry login/logout and update the documentation accordingly.

Registry authentication improvements:

• Added a new mechanism to resolve registry authentication with the following precedence: environment variables, stored credentials (msb login), Docker config, and finally anonymous access. This is implemented in the new resolve_registry_auth function in microsandbox-core/lib/management/image.rs, with comprehensive tests. The Registry::new constructor and all call sites were updated to accept an explicit RegistryAuth parameter. [1] [2] [3] [4]
• Introduced CLI commands msb login and msb logout for managing stored registry credentials, and updated CLI argument parsing to support their options.
• Updated CLI documentation to describe new authentication flows, environment variable support, and credential storage. [1] [2]

Fractional CPU support:

• Changed the cpus field in Sandbox, Build, and SandboxBuilder structs from u8 to f32, allowing fractional values (e.g., 0.5, 0.25). Updated related builder methods and all usages, including tests, to handle floating-point values. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

Other improvements:

• Changed the build_libkrun Makefile target to use bash explicitly for compatibility.

Note

I’m not a Rust expert, so I used coding agents, SDD, and the coding standards I know to implement these changes. I also reviewed all the code included in this PR.

Feel free to share corrections and suggestions.

[Leay15]

I found some strange behavior in a few cases that isn’t always consistent, and it seems related to how much hardware is available on the host machine. With CPU values < 1, initialization can get stuck and the portal never finishes starting up because it hasn’t been able to reserve the capacity required to begin.

I’m going to keep investigating and thinking about how this could be avoided. I was considering using something similar to Kubernetes behavior—reserving resources at startup and then readjusting them once the system is running.

I’m also open to any comments or suggestions on this.

[toksdotdev]

thanks for submitting the PR. could you split your changes into separate PRs. ty!

also, for the private registry changes, kindly rebase on #351 which modifies quite a lot of the layer pulling logic to support multiple registries. the auth mode is currently hardcoded, so that'd need to be changed to pick up credentials from the various mediums you proposed.

[Leay15]

@toksdotdev sure! Working on it!

[Leay15]

@toksdotdev I'm closing this PR to follow up on it in the PRs #362 #369 #368