Update SDK min and target version to >= Preview8

[ViktorHofer]

Update the SDK min version to Preview 8 final and update the target version to RC.1 latest.

Fixes #38902

[Dotnet-GitSync-Bot]

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.

[ViktorHofer]

Merging as all other legs already passed in the previous run and the allconfigurations now succeeded as well.

[BruceForstall]

@ViktorHofer @dotnet/runtime-infrastructure It looks like this change broke coreclr outerloop testing:

https://dev.azure.com/dnceng/public/_build/results?buildId=809051&view=results

Which means all pri-1 testing will fail

[safern]

I believe @jkoritzinsky was taking a look at this?

[jkoritzinsky]

Yep I'm looking at this today.

[BruceForstall]

@jkoritzinsky Are you still looking? Every test leg is failing this weekend.

[jkoritzinsky]

#42146 will fix it, but it hasn't been merged in yet.

[trylek]

OK, let me put out the PR for disabling the one test for now in issues.targets to unblock the pipeline.

[trylek]

I guess the interesting question is when the PR can be realistically merged in. If that's just around the bend, blocking the test out would cause more churn than good, but if we only get to it on Tuesday, it will be a grim Thursday at the CI council meeting ;-).

[BruceForstall]

I opened #42168 to track this.

btw, it looks like there are many thousands of warnings in the test build that I don't remember seeing before.

[trylek]

I asked about that on the internal infra e-mail alias and my understanding is that this is due to some more stringent checks in new Roslyn. Which is an interesting question, perhaps @jaredpar may have thoughts on what is the preferable way forward - either booking the time to clean the tests up to conform with the latest compiler version, or treating them as "set in stone" (which may be more appropriate e.g. for various regression tests) and maybe devising a new way to mark newly added tests as (potentially) conforming to a more stringent warning policy employed by the newest C# compiler.

[trylek]

Hmm, my bad, it's not as easy as blocking the test out in issues.targets as that only kicks in when building the XUnit test wrappers, not upon test build as such. I guess the easiest way forward (without the actual fix) is to either mark the test as Pri2 or block it out using the DisabledProjects item group in src/coreclr/tests/src/dirs.proj for now.