docs(azure): document Docker IGVM reproducibility

[Haitao Huang (haitaohuang)]

Summary

• remove doc/reproducible_build.md so the shared documentation matches intel/main
• add Docker-only Azure IGVM reproducibility guidance under sh_script/Azure/
• document the current dependency-locking, builder-image, and CI limitations
• update the Dockerfile and workflow references to the Azure-specific document

Validation

Documentation and references were checked against the current Azure Dockerfile, build wrapper, Makefile, and reproducibility workflow.

[Haitao Huang (haitaohuang)]

Nix feasibility investigation

Nix can provide a stronger reproducible Azure IGVM build than the current Dockerfile. A committed flake.lock can pin nixpkgs, the Rust-toolchain provider, and Rust dependency tooling; Nix store paths then identify exact compiler and system-package inputs. Sandboxed builds also prevent undeclared network or host dependencies. This addresses the current gap where only Cargo dependency versions are tracked by Cargo.lock, while APT and rustup artifacts can change when the builder image is rebuilt.

Proposed implementation

1. Add flake.nix and flake.lock for x86_64-linux, pinning nixpkgs, crane, and rust-overlay or fenix.
2. Import Rust 1.88.0, rust-src, and x86_64-unknown-none from the pinned Rust input. Declare Clang, LLVM, NASM, GCC/build tools, OpenSSL, OCaml, Autotools, CMake, Perl, Python, jq, and the SGX/DCAP build dependencies from pinned nixpkgs.
3. Include recursive Git submodules in the Nix source. Replace preparation steps that require submodule .git directories (git reset, git clean, and git apply) with an explicit derivation patch phase that applies the td-shim and spdm-rs ring patches to a writable source tree.
4. Use crane to vendor all registry and Git Cargo dependencies from Cargo.lock, then run Cargo with --locked and offline access inside the sandbox.
5. Define a custom Azure IGVM derivation that invokes the exact build-igvm target and installs migtd.igvm, its SHA-256, measurements, and build log into the Nix output.
6. Add CI using nix build .#azure-igvm --rebuild --keep-failed, and also compare builds from independent clean Nix stores or runners. During migration, compare the Nix-produced IGVM with the current Docker-produced IGVM before making Nix authoritative.
7. Optionally generate a Docker builder with dockerTools.buildImage if the existing Docker interface must remain available; the IGVM derivation itself does not require Docker.

The main engineering risks are the Git-dependent submodule preparation, mutable SGX/DCAP build tree, and any build scripts that assume an FHS filesystem. These need explicit Nix patch/build phases. Generated keys, signatures, and collateral must remain fixed inputs; Nix cannot make intentionally generated cryptographic material deterministic.

References: Nix reproducibility checking, Nix Docker image tooling, crane, and rust-overlay.

This is a feasibility/design result only; Nix is not installed in the current environment, so no prototype was built in this PR.