Move test with expected crash to outerloop

[elinor-fung]

Contributes to #65000

• Re-enable core dumps on OSX for libraries test runs
• Move test with expected crash (PosixSignalRegistrationTests.SignalCanCancelTermination with SIGQUIT, not cancelled) to outerloop
• Disable test with expected crash OSX - trying to upload the core dump will still cause timeouts / leave machines in bad states until we have https://github.com/dotnet/core-eng/issues/15333#issuecomment-1034275061.

[ghost]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

---

null

Author:	elinor-fung
Assignees:	elinor-fung
Labels:	area-System.Runtime.InteropServices
Milestone:	-

[elinor-fung]

/azp run runtime-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[danmoseley]

My next idea if needed is to serialize such tests, and wrap them in code (flag to remote executor) that deletes any core dumps that did not exist when the test began.

[elinor-fung]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[elinor-fung]

With this, the expected crashes are happening in outerloop. The timeout in runtime-libraries-coreclr outerloop (Libraries Build OSX x64 Debug) is from still trying to upload that 6GB dump. Perhaps we should disable that one case on macOS until we have something for https://github.com/dotnet/core-eng/issues/15333? cc @stephentoub

Jobs
| where Source == "pr/public/dotnet/runtime/refs/pull/65114/merge"
| join kind=inner Files on JobId
| where FileName startswith "core."
| join kind=inner WorkItems on WorkItemId
| where FriendlyName == "System.Runtime.InteropServices.Tests"
| project
  QueueAlias,
  Pipeline = tostring(parse_json(Properties).DefinitionName),
  PhaseName = tostring(parse_json(Properties)["System.PhaseName"]),
  FileName,
  SizeBytesLong

QueueAlias	Pipeline	PhaseName	FileName	SizeBytesLong
alpine.314.amd64.open	runtime-libraries-coreclr outerloop	libraries_build_Linux_musl_x64_Debug	core.1000.45	71311360
centos.7.amd64.open	runtime-libraries-coreclr outerloop	libraries_build_Linux_x64_Debug	core.1000.45	161980416
debian.10.amd64.open	runtime-libraries-coreclr outerloop	libraries_build_Linux_x64_Debug	core.1000.40	121303040
osx.1200.amd64.open	runtime-libraries-coreclr outerloop	libraries_build_OSX_x64_Debug	core.85967	6374526976
osx.1200.arm64.open	runtime-libraries-coreclr outerloop	libraries_build_OSX_arm64_Debug	core.83841	5638848512
redhat.7.amd64.open	runtime-libraries-coreclr outerloop	libraries_build_Linux_x64_Debug	core.1000.11659	133410816
ubuntu.1804.amd64.open	runtime-libraries-coreclr outerloop	libraries_build_Linux_x64_Debug	core.1000.982	141942784

[elinor-fung]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[elinor-fung]

This should mitigate #65000 while re-enabling dumps for real (unexpected) failures.

Verified via Kusto that the dump files for the expected crash are being created as part of tests in 'runtime-libraries-coreclr outerloop' runs now (and not created for the disabled OSX case), while they were in the 'runtime' run before.

The runtime-libraries-coreclr outerloop failures on Linux are unrelated (#58616).