Define a reproducibility validation test for the SDK tarball

[mthalman]

Summary

Add a test that validates the reproducibility of the .NET SDK tarball build by comparing the output of two builds of the same commit. The test asserts the two tarballs are identical (or differ only in known, baselined ways).

Background

The parent issue (#4963) tracks making .NET's build deterministic/reproducible. A key part of this effort is having a test that continuously validates reproducibility so regressions are caught. There is currently no test that validates byte-for-byte reproducibility of the build output.

Test Design

Test Location

The test should live in test/Microsoft.DotNet.Tests/ alongside existing VMR-level tests.

Test Class

Create a new ReproducibilityTests class that:

1. Accepts paths to two SDK tarballs built from the same source commit.
2. Extracts both tarballs and compares their contents.
3. Performs byte-level comparison of all files, identifying any files that differ between the two builds.
4. Uses exclusion system to filter out known non-reproducible files.
5. Uses baseline comparison system to compare the list of differing files against a baseline. Any new non-reproducible file causes the test to fail; any file that becomes reproducible causes the baseline to be stale (and should be updated).
6. Generates updated baseline/exclusion files in the logs directory so that CI can publish them for easy baseline maintenance.

Conditional Test Execution

The test should be conditional on both tarball paths being provided.

Pipeline Design

Obtaining the Two Builds

The priority right now is to test reproduceability for source-only builds so these will be the build types that are targeted for this workflow.

The test pipeline follows the same pattern as eng/pipelines/templates/jobs/sdk-diff-tests.yml to locate and download artifacts from a prior dotnet-unified-build run:

1. Find the associated dotnet-unified-build run. Use the same logic as sdk-diff-tests.yml:

   • If triggered by a pipeline resource, use the triggering pipeline's run ID and commit SHA.
   • Otherwise, query for the latest completed run on the current branch.

2. Download the SDK tarball from the identified dotnet-unified-build run using the existing download-vmr-artifact.yml template. This becomes the "first build" tarball.

3. Checkout the VMR at the same commit as the dotnet-unified-build run.

4. Run a second build of the SDK at that commit, producing a second SDK tarball. This build should use the same build flags/configuration as the original.

5. Run the ReproducibilityTests passing both tarball paths.