persist: migrate to the GA Azure SDK crates

[jasonhernandez]

Replaces azure_core / azure_identity / azure_storage / azure_storage_blobs 0.21 with the 1.x GA line: azure_core 1.1, azure_identity 1.0, azure_storage_blob 1.0.

This is a rewrite of the earlier version of this PR, which targeted the 0.35 preview series and was stacked on the reqwest 0.13 workspace bump. Both of those premises changed:

• The Azure SDK for Rust reached 1.0 GA (azure_core 1.0 in May, 1.1 in July), so there is a stable line to target instead of a preview.
• The reqwest 0.13 workspace bump landed twice (Bump reqwest to 0.13 #36215, reqwest: re-apply 0.13 bump at 0.13.4 with explicit TLS backend pin #37469) and was reverted twice (Revert "Bump reqwest to 0.13 (#36215)" #36241, Revert "reqwest: re-apply 0.13 bump at 0.13.4 with explicit TLS backend pin" #37491), and main is back on 0.12.28. This PR no longer depends on it. Azure gets reqwest 0.13 through a reqwest_0_13 workspace alias; the workspace reqwest stays at 0.12.28. reqwest 0.13.4 is already in the tree via sentry/opentelemetry and already exempted in deny.toml, so this adds no new duplicate-version debt. When a third 0.13 attempt sticks, the alias collapses to a one-line change.

Net effect: -305 lines of our own code and -183 lines of Cargo.lock. The 0.21 series is unmaintained and drags an unmaintained HTTP stack with it (http-types, RustyXML, oauth2, async-std's executor pieces), which is also how one RUSTSEC exemption retires here.

The big win: CLO-190's workaround is now upstream

main carries a 426-line RefreshingWorkloadIdentityCredential (#38178, CLO-190). It exists because azure_identity 0.21's WorkloadIdentityCredential read AZURE_FEDERATED_TOKEN_FILE once at construction and held the contents for process lifetime. Kubernetes rotates that projected token, so once the last cached AAD access token expired, every refresh presented an expired client assertion and a long-running process was permanently locked out of blob storage.

azure_identity 1.0 fixes this upstream: WorkloadIdentityCredential now holds a ClientAssertion that re-reads the token file on a 10-minute interval (workload_identity_credential.rs, TIMEOUT = 600s). The whole module and its two tests are deleted.

The one behavior we lose is .trim() on the token file contents. Kubernetes writes the projected token without surrounding whitespace, so this only affected hand-provisioned files, which the CLO-190 comment already called out as the edge case.

Credential chain

create_default_credential() no longer exists in 1.x, so the chain is assembled in azure.rs: workload identity → managed identity → developer tools, tried in order on each token request.

That covers the same credential types 0.21's DefaultAzureCredential did (App Service MI + VM/IMDS MI collapse into ManagedIdentityCredential; Azure CLI + azd collapse into DeveloperToolsCredential) minus EnvironmentCredential, which 1.x dropped and which we never provisioned. Managed identity is in the chain, which resolves the open risk the previous version of this PR flagged.

Sources are re-tried per token request rather than latching onto the first that worked, matching 0.21's behavior — construction-time selection is not an option because ManagedIdentityCredential::new succeeds on any host and would shadow the developer-tools fallback on a laptop.

API migration in src/persist/src/azure.rs

• ContainerClient → BlobContainerClient, built from a single container URL rather than (account, container).
• blob_client.get().into_stream() → blob.download(None). 1.x issues parallel range requests internally and returns one body stream, so the hand-rolled FuturesOrdered over the SDK's chunk pager goes away.
• blob.put_block_blob(value) → blob.upload(value.into(), None).
• get_properties / delete / create take None options; list_blobs yields BlobItems from a Pager.
• Error::as_http_error().status() → Error::http_status() (also in location.rs).

What to scrutinize

src/persist/src/azure/azurite.rs (new, 191 lines). The one part worth reading line by line, against the Shared Key spec. 1.x dropped the emulator credential and Azurite accepts only Shared Key, so a per-try policy signs each request. Notes:

• The canonicalized resource repeats the account name (/devstoreaccount1/devstoreaccount1/container/...). That looks wrong and isn't: Azurite runs with --disableProductStyleUrl, so the account is addressed through the URL path and Azurite prepends the account it resolved. Signing it any other way returns AuthorizationFailure. There is a NOTE: on this.
• The emulator client pins x-ms-version to 2025-01-05. The SDK's default is 2026-04-06, which our pinned Azurite 3.33.0 rejects outright with InvalidHeaderValue.
• Signing uses azure_core::hmac::hmac_sha256 (the hmac_rust feature) rather than a direct hmac dependency.
• It is not #[cfg(test)]-gated. mzcompose points persist at http://devstoreaccount1.azurite:10000/container using optimized builds, so gating this behind cfg(test) would break every mzcompose test that uses Azurite as the blob store. The Azurite key is a publicly documented constant and this path is only reachable for the equally well-known devstoreaccount1 account name.

The custom transport client. Still needed: the SDK's own client hardcodes 20s connect / 60s read timeouts and ignores BlobKnobs. Two deliberate choices:

• .tls_backend_rustls() — explicit rather than relying on reqwest 0.13's default, so an unrelated dependency enabling native-tls cannot silently move Azure traffic onto it. This is the ccsr lesson from reqwest: re-apply 0.13 bump at 0.13.4 with explicit TLS backend pin #37469.
• .no_gzip().no_deflate().no_brotli().no_zstd() — required, not hygiene. reqwest enables auto-decompression by default for every codec whose feature is on, and the SDK turns on gzip and deflate. BlobClient::download reassembles a blob from range requests keyed by byte offset, which a transparently decompressed body invalidates. The SDK's own apply_client_defaults disables decompression for exactly this reason; a custom transport has to do it itself.

get's response-length metric. In 1.x, content_length on a download result describes only the initial range, not the whole blob, so comparing it against total bytes read would fire get_invalid_resp on every multi-part download. total_len() reads the total out of Content-Range when present and falls back to content_length for blobs served unranged.

deny.toml

• Drops the exemptions the 0.21 chain needed: duplicate async-channel / event-listener / fastrand / futures-lite / getrandom 0.1 / rand 0.7 / rand_chacha 0.2 / rand_core 0.5, and the azure_svc_blobstorage log wrapper.
• Retires RUSTSEC-2026-0174 (http-types), which only entered the tree through the azure_* crates.
• Adds a log wrapper for rustls-platform-verifier, which arrives with reqwest 0.13's rustls backend.
• Re-points the quick-xml 0.31 skip comment at junit-report, its actual source now.

Test plan

• cargo check --workspace --all-targets — clean
• cargo clippy -p mz-persist --all-targets — clean
• bin/fmt, bin/lint-cargo, bin/unused-deps — clean (time dropped from mz-persist, it was only used by the deleted credential)
• cargo deny check bans sources licenses — ok. advisories fails only on the pre-existing h2 RUSTSEC-2026-0258, verified identical on main.
• cargo test -p mz-persist against a real Azurite — 18/18 pass, including azure::tests::azure_blob. This was the previous version's biggest open item: the Shared Key path had only ever been type-checked. Verified against mcr.microsoft.com/azure-storage/azurite:3.33.0 with the same flags misc/python/materialize/mzcompose/services/azurite.py uses, with Azurite debug logging on to confirm zero Validation failed lines across the full blob_impl_test suite (GET/PUT/HEAD/DELETE/list, including the empty-blob and ranged-read paths). Finding and fixing the canonicalized-resource bug came out of this.

doc/developer/generated/persist/azure.md still refers to azure_storage_blobs. That tree is maintained solely by the update-docs agent, so it is left alone here.

Part of SEC-619.

🤖 Generated with Claude Code