refactor: migrate to more permissive/accurate String parameter types

[jschillem]

The API exclusively accepted String parameters before. This is forcing an unergonomic API for users by forcing them to allocate a String for an internal detail.

This PR changes all APIs that previously accept String into generic impl Into<String> or impl AsRef<Path>. These changes are backwards compatible as String implements both of these trait bounds.

The only breaking change is converting the return type of child_process_create_ns in ns.rs to Result<PathBuf, Error>. This is more accurate to what should be returned as it is returning a file path. However, I am also wondering why this function is exposed as public while its wrapping function child_process is not.

[gemini-code-assist]

Code Review

This pull request refactors various functions and API methods to use more idiomatic Rust types for string and path arguments, specifically replacing String with impl Into<String> and impl AsRef<Path>. This improves ergonomics by allowing callers to pass string literals or references without explicit conversions. However, several issues were identified in the src/ns.rs file, including a compilation error due to the use of non-existent methods on PathBuf and Path, as well as redundant path manipulation logic.

[cathay4t]

So you suggest me to make breaking changes and fancy trait argument just because unergonomic.

No, this is premature optimization to me and solve no real problem. The allocation of String is always there because we need to generate netlink packet data, this change just move this allocation to somewhere else.

Yes, we bump version always, but it does not mean we break API arbitrarily.

[jschillem]

So you suggest me to make breaking changes and fancy trait argument just because unergonomic.

No, this is premature optimization to me and solve no real problem. The allocation of String is always there because we need to generate netlink packet data, this change just move this allocation to somewhere else.

Yes, we bump version always, but it does not mean we break API arbitrarily.

I agree that the allocation is always there, however I'd argue that changing it to perform the allocation within the library code is useful to provide a better interface for users. Using the Into<String> trait still signals to the user that an allocation is necessary because String is owned. It just allows the user to pass &str as well.

As for the breaking changes aspect, none of the trait bound arguments would be a breaking change. I completely understand being against the PathBuf return type change as that is a breaking change.

[cathay4t]

Please give me more time to check out how other famous crate handle this String argument stuff.

For PathBuf, let's change it when real user complaint about it.