add process rlimits fail test

[ntkm61027]

Description

Implement integration test for process_rlimits_fail.
Port the test from runtime-tools/validation with a different approach.

While the original test in runtime-tools/validation/process_rlimits_fail/process_rlimits_fail.go tests by passing an invalid rlimits type (RLIMIT_TEST), this implementation takes a different approach since PosixRlimitBuilder uses a strictly typed enum (PosixRlimitType) that prevents invalid types at compile time.

Instead, this test validates the error handling by setting extremely high values (u64::MAX) for both hard and soft limits, which exceeds system limitations.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Performance improvement
• Test updates
• CI/CD related changes
• Other (please describe):

Testing

• Added new unit tests
• Added new integration tests
• Ran existing test suite
• Tested manually (please provide steps)

Related Issues

related #361 (process_rlimits_fail)

[YJDoc2]

Hey @ntkm61027 , thanks for the PR!
I had a question with this, can you please help me understand it - In the original go test, it is setting rlimit for RLIMIT_TEST , which is not a valid rlimit and hence it fails. However in this PR, we are setting a valid rlimit, but setting it to u64::max . Can you tell me why it is supposed to fail? Is there a Linux internal limit on max value of this, and u64::max is greater than that, so this fails?

Currently the CI is passing, so the logic in your test seems to be correct, but I don't understand why it is working.
Maybe also add corresponding explaining comment in the code as well.

[ntkm61027]

@YJDoc2
Thank you for your question!
Let me clarify with the specific documentation from Linux man pages.

According to man 2 setrlimit, the EPERM error occurs when:

The caller tried to increase the hard RLIMIT_NOFILE limit above the maximum defined by /proc/sys/fs/nr_open

In our test case:

1. We are using a valid rlimit type (RLIMIT_NOFILE)
2. But setting it to u64::MAX (18446744073709551615), which is significantly higher than the system's nr_open limit (default: 1048576)
3. The kernel correctly rejects this with EPERM because it exceeds the maximum allowed value

This approach still tests the OCI spec requirement that "The runtime MUST generate an error for any values which cannot be mapped to a relevant kernel interface", just from a different angle than the original Go test:

• Original Go test: Tests with invalid type (RLIMIT_TEST)
• This implementation: Tests with valid type but unmappable value (exceeding nr_open limit)

I added these implementation details as comments in the code as well.

[YJDoc2]

Hey @ntkm61027 thanks for the explanation and comments. That makes sense.
CI is failing due to format errors, can you run cargo fmt and fix the formatting.
Additionally, can you also put the kernel doc link that you have added in above comment in the code doc comment as well?
Apart from that, lgtm, so will merge after fix.

Thanks for your contribution!

[ntkm61027]

@YJDoc2
Oops, fixed it! Mind taking another look?
Thanks for the review!

I forgot to add the kernel doc link! Just a moment please!

[YJDoc2]

lgtm!

[YJDoc2]

Hey @ntkm61027 thanks for updating with changes. Also, congratulations on your first contribution to Youki!