HTTP warnings are not raised in dotnet tool scenarios

[nkolev92]

Describe the bug

Since the migration of dotnet tool installation to a custom installation instead of the restore, some of the restore checks are no longer happening.

In particular, there's no http warnings. I don't see them added in https://github.com/dotnet/sdk/pull/33835/files.

You can read more about that in:
https://devblogs.microsoft.com/nuget/https-everywhere/
https://devblogs.microsoft.com/nuget/https-everywhere-update/

Note that these warnings are important for the security push and that there are plans to explicitly error when HTTP feeds are used in .NET 9, so we should have them added soon.

The work should be minimal for this.
You can see an example in https://github.com/NuGet/NuGet.Client/blob/6690f77743f3e2d4e062b2722a09710085ca674c/src/NuGet.Core/NuGet.Commands/RestoreCommand/RestoreCommand.cs#L242-L254.

cc @aortiz-msft @zivkan

To Reproduce

Run dotnet tool install with an http feed.

Exceptions (if any)

Further technical details

• Include the output of dotnet --info
• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[nkolev92]

It'd be great to make this addition to the general package downloader on the SDK side, so that scenarios like workloads also raise the equivalent warnings.

[baronfel]

Thanks for raising this - I'll add it to our tools backlog for the team to hit. I agree we should fix this. It would make things more consistent if that string resource was accessible via the packages - is that the case?

[nkolev92]

No, all resources are internal. Given that we ship the packages as well, we try to maintain a smaller API surface area.

[JL03-Yue]

Thanks for reporting this.