Introduce iossimulator RIDs, and convert as needed

[directhex]

Previously, we have had four iOS RIDs:

• iOS-arm
• iOS-arm64
• iOS-x86
• iOS-x64

Apple has never shipped an iOS device with an x86 or x64 processor. Instead, the x86/x64 RIDs have meant "iOS simulator with these arches" as opposed to "iOS with these arches". Amongst other things, that means building against a DIFFERENT SDK, iPhoneSimulator.platform vs iPhoneOS.platform

In the Apple Silicon future, the iOS simulator is now an ARM64 binary - so we need:

• iOS-arm
• iOS-arm64
• iOS-arm64, but built against the simulator SDK not the device SDK
• iOS-x86
• iOS-x64

Clearly, there's a problem.

The solution is to move the simulators to a different RID, to avoid the overloading issue:

• iOS-arm
• iOS-arm64
• iOSSimulator-arm64
• iOSSimulator-x86
• iOSSimulator-x64

This PR introduces the new entries in the RID graph, moves our existing iOS-x{86,64} to iOS-sim-x{86,64}, adds a new iOS-arm64.

The above also applies for tvOS, with a smaller set of OSes:

• tvOS-arm64
• tvOSSimulator-arm64
• tvOSSimulator-x64

Ref: #48216

[dotnet-issue-labeler]

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

[directhex]

Private run: https://dev.azure.com/dnceng/internal/_build/results?buildId=1027906&view=results

[steveisok]

Hmm... it doesn't look like the iOS tests ran on any of the configurations. They should also be on the staging pipeline, but for some reason they aren't.

[directhex]

The packaging build passed.

[directhex]

OK, so here's the summary:

• This should be fine now, BUT, iossimulator is a child of ios not unix
• If I make it a child of unix, the build breaks
• As far as I can understand it, the build is using values for KnownFrameworkReference from outside the build tree (maybe https://github.com/dotnet/installer/blob/master/src/redist/targets/GenerateBundledVersions.targets#L107-L119) so the iossimulator-x64 RID isn't considered as valid - but when its parent is ios-x64, the implicit relationship is treated as okay
• If we don't want to parent on iOS, we probably need to make changes to dotnet/installer, and/or hack in an override like https://github.com/ViktorHofer/runtime/blob/296aaf818ec02101226845aea39ca14d32519cf2/src/libraries/pkg/test/frameworkSettings/net6.0/settings.targets#L7-L16 (@ViktorHofer?)

IMHO since there are multiple intersecting concerns across multiple repos, we should parent on iOS for now, and fix it up later once the changed RIDs are in. Either way there's coordinating across multiple repos needed to avoid build breaks

[ViktorHofer]

If we don't want to parent on iOS, we probably need to make changes to dotnet/installer, and/or hack in an override like https://github.com/ViktorHofer/runtime/blob/296aaf818ec02101226845aea39ca14d32519cf2/src/libraries/pkg/test/frameworkSettings/net6.0/settings.targets#L7-L16 (@ViktorHofer?)

Yes, we should flow that information into dotnet/installer to make sure the package rids are known. And yes, if we would want to depend on that information before we can consume a new SDK, updating RIDs in the known items makes sense.

[ericstj]

iossimulator is a child of ios not unix

is iOS simulator a superset of iOS? That's how the RIDs are defined right now.

No, RID definitions do not imply superset. They just indicate possible reuse. iossimulator may reuse ios assets as a child of ios. It doesn't have to. Just like linux-musl is a child of linux but is not a superset of linux.

The parenting of a RID should be done to maximize potential reuse: pick a parent that will have the most reuse.

In this specific case consider an asset which targets:
unix and ios, say

runtime/src/libraries/System.Console/src/System.Console.csproj

Line 4 in 43e5ae1

<TargetFrameworks>$(NetCoreAppCurrent)-windows;$(NetCoreAppCurrent)-Unix;$(NetCoreAppCurrent)-Android;$(NetCoreAppCurrent)-iOS;$(NetCoreAppCurrent)-tvOS;$(NetCoreAppCurrent)-Browser</TargetFrameworks>

Which asset is more likely to be reusable on iossimulator? If it's unix then make that the parent, if it's ios then make that the parent. Try to thing generally across many cases of cross-compilation and choose the option that will have the most reuse.