`NuGet` Download step in CI introduces flakiness

In a PR to address the flakiness in dotnetup, that PR actually failed due to a different flaky issue. https://github.com/dotnet/sdk/pull/55208
```
at InstallNuGet, D:\a\_work\1\s\eng\restore-toolset.ps1: line 61
at InitializeCustomSDKToolset, D:\a\_work\1\s\eng\restore-toolset.ps1: line 52
at , D:\a\_work\1\s\eng\restore-toolset.ps1: line 320
at InitializeCustomToolset, D:\a\_work\1\s\eng\common\build.ps1: line 99
at Build, D:\a\_work\1\s\eng\common\build.ps1: line 105
at , D:\a\_work\1\s\eng\common\build.ps1: line 194
at , : line 1
The request was aborted: Could not create SSL/TLS secure channel.
```

It appears the NuGet download step can sometimes fail in CI.

This can be observed here: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1501774&view=logs&jobId=cc0c8ce4-bcb9-5d43-b4e1-7b7d984b2587

cc @MichaelSimons

This also makes me wonder why the network is so unstable in our CI machines. (do we have tests running on that machine at the same time that are disabling internet access for example... surely not... are the machines themselves hosted somewhere with poor connections?)

Start at eng/restore-toolset.ps1:61 in InstallNuGet and trace its callers at lines 52 and 320, then review the failed PR 55208 and Azure build 1501774 logs. Determine the failure pattern and define done as preventing or reliably handling this NuGet download failure in CI, with validation against the affected build path.

Written by the indexing model from the issue text.