This change moves linux-bionic out of the runtime-staging pipeline and into runtime-extra-platforms. The effect is that all linux-bionic runs will be post PR unless triggered manually.

The multi-reg restrictions do not apply to them.

* Adding a regression test for dotnet/performance#2575

* Ensure that the result span is fully initialized.

* Fixed GC collecting listener and/or connection while waiting on new connection/stream event

* Minor fixes and cleanups

[main] Update dependencies from 9 repositories


 - Merge branch 'main' into darc-main-1b91a625-558f-4732-8098-a4d9458b1134

 - Merge branch 'main' into darc-main-1b91a625-558f-4732-8098-a4d9458b1134

Avoids running these legs per PR in runtime-staging and places them in a more appropriate place.

* Simplify platform macro definitions in PAL

* Address CR feedback

* Rename unwinder.cpp to baseunwinder.cpp

* Sync arm64 DAC_CS_NATIVE_DATA_SIZE

[main] Update dependencies from dotnet/linker

Issue was that if a BGC thread handles a mark stack overflow, but runs into yet another mark stack overflow on another heap, we set a flag on the region, and the containing heap. However, the BGC handling the other heap may have already decided to move on, and may thus not see the flag. (#74571)

Fix is to set the flag on the heap doing the scan rather than the heap containing the object causing the mark stack stack overflow. The thread handling that heap will indeed recheck the flag and rescan if necessary. This necessitates another change because in the concurrent case, we need each BGC thread to enter mark stack overflow scanning if there was a mark stack overflow on its heap. So we need to propagate the per-heap flag to all the heaps.

Fixed another issue for regions where the small_object_segments local variable in background_process_mark_overflow_internal would be set incorrectly in the non-concurrent case. It would be set to FALSE as soon as all the regions for gen 0 are processed.

This reverts commit 02c2ba0e.

* DisableRuntimeMarshalling block Vector types

When DisableRuntimeMarshalling is set, the runtime should block
a bad-list for blittable types.

This doesn't address the case where the P/Invoke is inlined.

* Update dependencies from https://github.com/dotnet/arcade build 20220823.2

Microsoft.DotNet.ApiCompat , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.TargetFramework , Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.GenAPI , Microsoft.DotNet.GenFacades , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.SharedFramework.Sdk , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.XUnitExtensions
 From Version 7.0.0-beta.22419.1 -> To Version 7.0.0-beta.22423.2

* Update dependencies from https://github.com/dotnet/arcade build 20220824.3

Microsoft.DotNet.ApiCompat , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.TargetFramework , Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.GenAPI , Microsoft.DotNet.GenFacades , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.SharedFramework.Sdk , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.XUnitExtensions
 From Version 7.0.0-beta.22419.1 -> To Version 7.0.0-beta.22424.3
Co-authored-by: Ndotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

* Fix: Initial attempt to fix - ut passed

* Update: Forgotten save

* Update: Clear and Dispose ops on handles

* Update: Activate tests for Unix and correct no reuse behavior

* Update: Review Changes

* Update: Deleted forgotten comment

* Update: Review change

Document the recent engineering system improvements

* CI: Tighten the path based triggers for jobs

`subsets`:
- `mono`: exclude all `src/mono/wasm`, since any changes in that will
  trigger the wasm jobs anyway
- `runtimetests`: exclude Wasm.Build.Tests, and Wasm.Debugger.Tests,
  both of which are in `src/tests/BuildWasmApps`, but are *not* related
  to runtime tests.
- `coreclr_jit`: exclude `src/mono/*` completely, unrelated.

Also, exclude `eng/pipelines/common/evaluate-default-paths.yml` from all
the subsets, so changes in that doesn't trigger unncessary builds.

* Address review feedback

* Re-enable MemoryCacheTest.Contains. Add a little more info in case of failures.

Partially reverts https://github.com/dotnet/runtime/pull/68991

When LLVM code calls non-LLVM code it will pass arguments in SIMD
registers which the non-LLVM code doesn't expect

Fixes https://github.com/dotnet/runtime/issues/73454 (issue 1)

* update Helix arm64 images

* update images

* fix conditions

* uopdate docker images

* update containers

* update debian containers

* update ubuntu

* update ubuntu

* Reenable class-memaccess warning

* Match x64 logic in emitarm.cpp

* Make GCProtect sections with "gc" variable consistent
Co-authored-by: NJan Kotas <jkotas@microsoft.com>

* Disable ConnectWithRevocation_ServerCertWithoutContext_NoStapledOcsp on NativeAoT
* Disable tests against #70981 instead

An evaluation of the cost of "Copy native test components to test output folder" indicates that there are 2 major performance bottlenecks in that routine.

There are the findings I had
1. The routine spends significant time loading every test project into msbuild to determine what to do. This processing takes as much as 400ms per test on hardware which has slow IO performance.
2. On Unix platforms, when producing the test script binaries, we make the scripts executable by using chmod. This ALSO takes as long as 400ms on the slowest platforms.
3. Actually copying the native binaries around is extremely cheap and fast, and the cost to generate the test scripts is also fairly low.

This change addresses both of these issues.
1. For the issue that we look into each test project to determine what to do, I observed that for tests which are pri1 tests, when running a pri0 only job, we don't need to even examine any of the tests marked as exclusively pri1. This is a bit of a hack, but it does seem to work quite well.
2. For the chmod issue, since we don't actually maintain the executable bit when sent to helix, I set an msbuild property when generating the scripts during the "Copy native test components to test output folder" to just not set that flag.

Results:
Mac OSX test run jobs take ~8 minutes to run this portion of the build, down from ~27 minutes. Performance improvements are visible on all architectures/OS pairings, but they aren't as dramatic.

Fixes tests on big endian platforms.

To unblock CI build failures, works around #74170

* [wasm] Move stable jobs from runtime-staging to runtime

- library tests: windows
- AOT tests: windows
- Debugger tests (chrome): windows, and linux
- Wasm.Build.Tests: windows

* Move last remaining wasm-firefox tests to runtime too

* Move firefox debugger tests to runtime-extra-platforms

* Fix browser-eventpipe build

```
src/mono/sample/wasm/browser-eventpipe/Program.cs(80,13): error IDE0074: (NETCORE_ENGINEERING_TELEMETRY=Build) Use compound assignment
```

**BYPASS_SECRET_SCANNING**

System.Runtime.Serialization.Schema isn't getting a NuGet package created for it because it doesn't set IsPackable=true.

This change was attempted before in https://github.com/dotnet/coreclr/pull/23029 and rejected due to performance impact. Things have changed since then that makes it feasible now.

Sockets and file I/O do not use pinning feature of Overlapped anymore. They pin memory on their own using `{ReadOnly}Memory<T>.Pin` instead. It means that the async pinned handles are typically not pinning anything. The async pinned handles come with some extra overhead in this common use case. Also, they cause confusion during GC behavior drill downs. This change removes the support for async pinned handles from the GC:
- It makes the current most common Overlapped use cheaper. It is hard to measure the impact of eliminating async pinned handles exactly since they are just a small part of the total GC costs. The unified fully managed implementation enabled simplificication of the implementation and reduced allocations.
- It gets rid of confusing async pinned handles behavior. The change was actually motivated by a recent discussion with a customer who was surprised by the async pinned handles not pinning anything. They were not sure whether it is expected behavior or whether it is a bug in the diagnostic tools.

Micro-benchmarks for pinning feature of Overlapped are going to regress with this change. The regression in a micro-benchmark that runs Overlapped.Pack/Unpack in a tight loop is about 20% for each pinned object. If there is 3rd party code still using the pinning feature of Overlapped, Overlapped.Pack/Unpack is expected to be a tiny part of the end-to-end async flow and the regression for end-to-end scenarios is expected to be in noise range.

* #50575 colorbehavior default should disable colors in android/applemobile

* Only stack allocate when marshalling Utf8 arguments

Fixes #74394.

* Review feedback

This change enables caching of the last used writeable mapping for
W^X. It was originally disabled by an ifdef, but after we've turned W^X
on by default, performance tests have shown a regression in some regex
tests. I have investigated those and found that they do excessive amount
of jitting (around 50000 methods). Enabling the caching of the last used
writeable mapping fixes the regression completely.
The caching implementation was present in the sources ever since I've
implemented the W^X stuff, but if was disabled by an ifdef. So this
change just defines the related symbol and enables the code.

The caching basically just keeps a writeable mapping after unmapping
until the next mapping request arrives, so it gives an opportunity to
reuse it in case of series of mappings of sequential range of executable
memory, which happens e.g. in the case mentioned.