[build] skip DownloadOneFileWithRetry on no-op builds (#11693)

A no-op build binlog showed `DownloadOneFileWithRetry` running 17 times
for a total of ~20s on a 77s no-op build: every invocation re-hashed an
already-cached file (e.g. xamarin-android-toolchain-L_18.1.6-8.0.0-1.7z,
build-tools_r36_macosx.zip) just to confirm the SHA-256 still matches.
The Hash MSBuild task showed maxDurationMs=2005 per call across 32
invocations. Nothing changes on a no-op build, so this work was pure
waste.

Add a per-file stamp file (`<cache>/<file>.<SHA>.stamp`, or `.stamp`
when no hash is supplied) that gets touched once the download and SHA
verification succeed, and gate the target with:

  Inputs=`$(MSBuildThisFileFullPath)`
  Outputs=`$(_DownloadPath);$(_DownloadStamp)`

so MSBuild''s incremental engine skips the target - and the expensive
re-hash - on no-op builds. Self-heal is preserved:

  * Cached file deleted -> output missing -> target re-runs.
  * `_DownloadSha256` updated in a caller -> stamp file name changes ->
    new stamp output missing -> target re-runs and re-verifies.
  * This .targets file itself modified -> Inputs newer -> target
    re-runs.

The Touch lands after the SHA Error gate so a mismatch still fails the
build with the existing message and never persists a stale stamp.

### [build] only stamp file in Outputs; add self-heal helper

Listing the cached file in `Outputs` alongside the stamp defeats the
no-op gate when cache files restored from CI caches keep their original
old timestamps: Inputs.max (this targets file) > Outputs.min (the cache
file from a year ago) -> target re-runs and re-hashes every build.

Drop the cache file from `Outputs` and add `_PrepareDownloadOneFileWithRetry`
as `DependsOnTargets`.  It always runs (no Inputs/Outputs of its own) and
deletes the stamp when the cached file is gone, so MSBuild re-runs
DownloadOneFileWithRetry with a now-incomplete output set.

Verified end-to-end against `Xamarin.Android.sln`:

  BEFORE: 18 invocations, 22.53s of GetFileHash work on a no-op build
          (matches the user's reference msbuild.binlog at 20.08s)
  AFTER : 18 invocations, 1ms total - ALL skipped via Inputs/Outputs.
          Build wall: 101.94s -> 62.39s (~40s saved).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: jonathanpeppers

build-tools/scripts/DownloadFileWithRetry.targets

@@ -49,6 +49,23 @@
                                      whose contents drove the expected hash)
                                      so the next build re-fetches them.
 
+    Incremental no-op gate:
+      A per-file stamp file next to the cached download
+      (`$(_DownloadFolder)\$(_DownloadFileName).$(_DownloadSha256).stamp`,
+      or `.stamp` when no hash is supplied) is touched once the download
+      and SHA verification succeed. The target's `Inputs`/`Outputs` then
+      lets MSBuild skip re-running it - and re-hashing the cached file -
+      on no-op builds. The expected SHA is encoded in the stamp file
+      name so changing `_DownloadSha256` in a caller invalidates the
+      cached stamp and forces re-verification. Self-heal for a missing
+      cached file is preserved by `_PrepareDownloadOneFileWithRetry`,
+      which always runs and drops the stamp if the cached file is gone -
+      so this target's `Outputs` becomes incomplete and MSBuild forces
+      it to re-run. Only the stamp is listed in `Outputs`: including the
+      cached file there would defeat the gate, because cache files
+      restored from CI caches keep their original old timestamps and
+      would always look out of date relative to this targets file.
+
     Usage pattern. The `_DownloadFile` item group must be built inside the
     caller's target body (so the items are visible to `<MSBuild>`). Each
     item carries its per-file parameters as `AdditionalProperties` metadata,
@@ -81,13 +98,20 @@
     <DownloadFileWithRetryFile>$(MSBuildThisFileFullPath)</DownloadFileWithRetryFile>
     <_DownloadRetries>5</_DownloadRetries>
     <_DownloadRetryDelayMilliseconds>5000</_DownloadRetryDelayMilliseconds>
+    <!-- Computed up-front (vs inside the target body) so the per-file
+         destination and stamp paths are visible to the target's
+         Inputs/Outputs incremental gate below. Each `<MSBuild>` build
+         request that calls into this file gets its own evaluated
+         scope with these AdditionalProperties already set. -->
+    <_DownloadPath>$(_DownloadFolder)\$(_DownloadFileName)</_DownloadPath>
+    <_DownloadStamp Condition=" '$(_DownloadSha256)' != '' ">$(_DownloadPath).$(_DownloadSha256).stamp</_DownloadStamp>
+    <_DownloadStamp Condition=" '$(_DownloadSha256)' == '' ">$(_DownloadPath).stamp</_DownloadStamp>
   </PropertyGroup>
 
-  <Target Name="DownloadOneFileWithRetry">
-    <PropertyGroup>
-      <_DownloadPath>$(_DownloadFolder)\$(_DownloadFileName)</_DownloadPath>
-    </PropertyGroup>
-
+  <Target Name="DownloadOneFileWithRetry"
+      DependsOnTargets="_PrepareDownloadOneFileWithRetry"
+      Inputs="$(MSBuildThisFileFullPath)"
+      Outputs="$(_DownloadStamp)">
     <!-- Self-heal: if a cached file already exists AND we know the expected
          hash, verify it up-front. On mismatch, delete (along with any
          CleanupOnMismatch siblings) so the download attempts below actually
@@ -146,6 +170,23 @@
         Condition=" '$(_DownloadSha256)' != '' and '$(_DownloadActualSha256)' != '$(_DownloadSha256)' "
         Text="SHA256 mismatch for $(_DownloadFileName). Expected: $(_DownloadSha256) Actual: $(_DownloadActualSha256)"
     />
+
+    <!-- Record success so subsequent no-op builds can skip this target via
+         the Inputs/Outputs gate above (and avoid re-hashing the cached
+         file). Reached only when the SHA check above passed - or when no
+         hash was supplied to verify against. -->
+    <Touch Files="$(_DownloadStamp)" AlwaysCreate="True" />
+  </Target>
+
+  <!-- Self-heal helper for the Inputs/Outputs gate on DownloadOneFileWithRetry.
+       Always runs (no Inputs/Outputs of its own) and is cheap: a single Exists
+       check per file. If the stamp claims a previous successful validation but
+       the cached file is gone, we drop the stamp so the parent target sees its
+       Outputs as incomplete and re-runs to re-fetch. -->
+  <Target Name="_PrepareDownloadOneFileWithRetry">
+    <Delete Condition=" Exists('$(_DownloadStamp)') and !Exists('$(_DownloadPath)') "
+        Files="$(_DownloadStamp)"
+    />
   </Target>
 
 </Project>