Adopt consistent approach for defining InternalsVisibleTo in the repo

[silamon]

Fixes #41244. This pull request moves all InternalsVisibleTo from AssemblyInfo.cs to their respective project file (.csproj). When reviewing, compare them 2-by-2 since the csproj file is always next to the AssemblyInfo.cs file.

One exception: the RateLimiting project had already the InternalsVisibleTo declared. In this project the AssemblyInfo.cs is removed without applying changes to .csproj project file.

[ghost]

Thanks for your PR, @silamon. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[dnfadmin]

All CLA requirements met.

[Tratcher]

Wow, that's a bigger change than I expected. Good job.

Something's failing in DataProtection?
https://github.com/dotnet/aspnetcore/pull/45748/checks?check_run_id=10286080432

[ghost]

Hey @dotnet/aspnet-build, looks like this PR is something you want to take a look at.

[silamon]

Something's failing in DataProtection? https://github.com/dotnet/aspnetcore/pull/45748/checks?check_run_id=10286080432

Yes, thanks for looking. Actually, it's not only in DataProtection. There are also a few cases in Kestrel.
Strange thing is that I've included the correct InternalsVisibleTo in the project. At least I think so, but I may miss some knowledge. :)

For example:
2022-12-24T11:26:45.6372501Z D:\a_work\1\s\src\Servers\Kestrel\Kestrel\src\WebHostBuilderKestrelExtensions.cs(37,76): error CS0122: 'KestrelServerOptionsSetup' is inaccessible due to its protection level [D:\a_work\1\s\src\Servers\Kestrel\Kestrel\src\Microsoft.AspNetCore.Server.Kestrel.csproj]

There's a InternalsVisibleTo declared in Microsoft.AspNetCore.Server.Kestrel.Core for Microsoft.AspNetCore.Server.Kestrel. So, I'm not really sure why it remains inaccessible. The namespace of KestrelServerOptionsSetup does have "Internal" and most of those DataProtection classes also have that, but this is more of an assembly thing if I understand correctly.

May it have something to do with the fact that I omitted the PublicKey?

[silamon]

Nevermind, I think I saw the problem.

[JamesNK]

The tests that use Moq and Castle.DynamicProxy are failing.

[Tratcher]

Thanks