Refactor: Dedicated checkpoint contest test group

[B4S1C-Coder]

Description

Added a dedicated checkpoint contest test group and moved checkpoint-only tests out of lifecycle.

The new group owns its container setup and cleanup through RAII context. checkpoint-restore has remain unchanged.

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)

Manual Validation

• Ran just contest-list and verified checkpoint exists

/workspaces/youki/scripts/build.sh -o /workspaces/youki -r -c contest
* FEATURES: <default>
* TARGET: x86_64-unknown-linux-gnu
   Compiling contest v0.1.0 (/workspaces/youki/tests/contest/contest)
    Finished `release` profile [optimized] target(s) in 1m 51s
removed '/workspaces/youki/runtimetest'
    Finished `release` profile [optimized] target(s) in 0.64s
/workspaces/youki/contest list
cgroup_v1_blkio
cgroup_v1_cpu
cgroup_v1_memory
cgroup_v1_network
cgroup_v1_pids
cgroup_v1_relative_network
cgroup_v2_cpu
checkpoint                 // <------- New Group-----------------------
checkpoint_restore
create
create_runtime
delete
devices
domainname_test
example
exec
exec_cpu_affinity
exec_env
fd_control
hooks
huge_tlb
intel_rdt
kill_container
kill_no_effect
killsig
lifecycle
masked_paths
memory_policy
mounts_recursive
net_devices
no_pivot
ns_itype
personality
pidfile
poststart
poststart_fail
poststop
poststop_fail
prestart
prestart_fail
process
process_capabilities_bounding
process_capabilities_fail
process_oom_score_adj
process_rlimits
process_rlimits_fail
process_user
prohibit_symlink
readonly_paths
root_readonly
rootfs_propagation
seccomp
seccomp_notify
set_host_name
set_io_priority
set_misc_props
set_scheduler_policy
start_container_hook_env_inherit
sysctl
time_ns
uid_mappings
update

• Also ran just test-content lifecycle before the cleanup tp compare the existing checkpoint behaviour.
• Ran the contest suite after cleanup.

Related Issues

Fixes #3641

Additional Context

The checkpoint group is sequential because CRIU checkpoint operations use global kernel resources and can interfere with one another.

[saku3]

There is a CI error in the Basic Checks, so please fix it.
If you haven't completed the DCO check yet, please do so as well.

[B4S1C-Coder]

I fixed the error in basic check and completed the DCO check. Just curious, is it possible for me to run these checks on my own fork as well? To avoid such issues in future.

[B4S1C-Coder]

@saku3 I resolved the merge conflicts. Please do let me know if anything is to be done from my end.

[B4S1C-Coder]

@saku3 just checking in on this, all the tests are passing. Let me know if anything else is needed to be done from my end. Thanks!

[nayuta723]

I left a nit comment. Please review the current main branch again and minimize the differences.

[nayuta723]

There is a significant difference in the bring_up_loopback implementation. Please align it with the current main branch, unless there was a specific reason for the changes.

[B4S1C-Coder]

Hi, thanks for having a look.

• The setup_network_namespace did not have the output.status.success() check. I have added this check, so now if ip link set up dev lo failed, it would get caught.

• checkpoint() was unconditionally calling setup_network_namespace on every checkpoint test (Now it does not do that, aliging with main branch).

PS. I used the name setup_network_namespace instead of bring_up_loopback because it felt more accurate, I can revert it if needed to match main exactly.

[B4S1C-Coder]

While rebasing I noticed that #3700 already wired checkpoint tests (leave-running, cgroup modes, link-remap, tcp-skip-in-flight, external namespaces) directly into ContainerLifecycle, including a TODO referencing this exact issue (#3641).

Given this overlap, I don't think it makes sense for me to push this forward right now. I'd be stepping on on-going work.

I'm going to step back from this PR. Feel free to close it, or let me know if you'd still like the dedicated checkpoint module approach and I can pick it back up.