containerd2: provide the capabilities of old-package containerd and obsolete it

[liunan-ms]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• The toolchain has been rebuilt successfully (or no changes were made to it)
• The toolchain/worker package manifests are up-to-date
• Any updated packages successfully build (or no packages were changed)
• Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• All package sources are available
• cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• LICENSE-MAP files are up-to-date (./LICENSES-AND-NOTICES/SPECS/data/licenses.json, ./LICENSES-AND-NOTICES/SPECS/LICENSES-MAP.md, ./LICENSES-AND-NOTICES/SPECS/LICENSE-EXCEPTIONS.PHOTON)
• All source files have up-to-date hashes in the *.signatures.json files
• sudo make go-tidy-all and sudo make go-test-coverage pass
• Documentation has been updated to match any changes to the build system
• Ready to merge

---

Summary

What does the PR accomplish, why was it needed?
As containerd2 package is introduced to azurelinux (#11427) and containerd2 will be default for AZL 3.0 AKS images (Azure/AgentBaker#5510). There will be conflicts when users install moby-engine in a VM or an AKS node with containerd2 installed as moby-engine requires containerd package. This PR adds "Provides/Obsoletes: containerd" to shift all installs of containerd to containerd2 and resolve the conflicts while installing moby-engine.

Expected scenarios:

• In a VM without any containerd package installed, a user is able to install moby-engine and containerd (v1.7.13) is automatically installed as its dependency.
• In a VM with containerd(v1.7.13) package installed, a user is able to install moby-engine.
• In a VM/cluster node with containerd2 (v2.0.0) package installed, a user is able to install moby-engine without conflicts.
• In a VM/cluster node with containerd(v1.7.13) package installed, a user cannot directly upgrade containerd to containerd2, they have to manually dnf remove containerd and install containerd2.

Change Log

• Add "Provides/Obsoletes: containerd" to shift all installs of containerd to containerd2

Does this affect the toolchain?

NO

Test Methodology

• Buddy build: https://dev.azure.com/mariner-org/mariner/_build/results?buildId=718016&view=results
• BVT tests: https://dev.azure.com/mariner-org/mariner/_build/results?buildId=718482&view=results
• Locally installed the containerd2 rpm in a cluster node and dnf installed moby-engine from PMC, tested by creating/removing a container with docker commands.