ABI-2 image isolation for the 3.0 transition

The unchanged server line must keep consuming ABI 2 while libdrizzle 3.0 is prepared. The server Containerfile defaults LIBDRIZZLE_IMAGE and WIREDTIGER_IMAGE to the respective quay.io/drizzle repositories’ abi2-testing-slim channels. The WiredTiger build and runtime stages also use the libdrizzle ABI-2 channel, and its build/upload/promote jobs publish the WiredTiger ABI-2 tag.

These tags follow compatible C++ builds until the 3.0 cutover. Before either image is built against ABI 3, remove its ABI-2 publication tag from the job configuration. Leave the last ABI-2 tags pointing to their existing images so unchanged consumers and rollback builds retain a served manifest. Do not retarget these channels to ABI 3.

A digest identifies content but does not retain it in Quay. Moving every tag off a manifest can make its digest unavailable; a build must not depend on an old digest whose tags have all moved. For an exact reproducible rollback, first publish and retain a distinct snapshot tag, verify its manifest and platforms, and then record that tag and digest together.

The server consumes libdrizzle directly and copies /usr/local from the WiredTiger payload image. A paired 3.0 candidate can override LIBDRIZZLE_IMAGE with its actual speculative image reference. Override WIREDTIGER_IMAGE as well when testing a rebuilt payload. Pass the same libdrizzle candidate to both WiredTiger stages when rebuilding it. Ensure candidate publication no longer includes the ABI-2 tags before using those overrides for a 3.0 build.

The images inspected for this transition provide linux/amd64. The ABI-2 channel names do not imply multi-architecture support: publish and verify arm64-compatible inputs before an arm64 3.0 promotion. Validate downstream builds and rollback inputs in Zuul before the packaging switch.