Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com>

* Added Span overloads for Socket.SendFile

* Updated ref

* Fixed doc comments

* Tests

* Remove test for non-blocking

Cf. dotnet/runtime#47230 (comment)

It causes a build warning on some newer compilers:

```
cc1plus: warning: command line option '-Wc++-compat' is valid for C/ObjC but not for C++
```

Co-authored-by: akoeplinger <akoeplinger@users.noreply.github.com>

* Initial change for sha256

* Handles intrinsics with 3 parameters

* Fix condition

* Revert test change to HelloWorld sample

* Update src/mono/mono/mini/mini-llvm.c

Co-authored-by: Ryan Lucia <ryan@luciaonline.net>

* Fixed format

Co-authored-by: Ryan Lucia <ryan@luciaonline.net>

If cancellation is requested at just the "wrong" time, we may end up canceling the operation but reporting it as a successful completion, due to our relying on _registration.Token being the caller-provided token, but that not being the case if cancellation was requested prior to UnsafeRegister being called, in which case it'll return a default registration.

All SPMI asm diffs (generated using superpmi.py) will
display interleaved GC info.

Note that you can also pass the `--gcinfo` option
to get traditional end-of-code asm dump, but that also
requires adding per-instruction offset output, which can lead
to excessive textual diffs.

* real fix needs to happen in TraceEvent

… processor affinity mask (#45943)

- Similarly to cases on Unixes where sched_getaffinity is available
- If `GCCpuGroup` and `Thread_UseAllCpuGroups` are both enabled, I'm not sure if the `CPUGroupInfo` count of active processors takes affinity into account as the docs are not clear, for now I'm not modifying that path until I can verify it
- Otherwise, a process that is started with a specific processor affinity mask still shows full CPU count
- This is one of the differences in the portable managed thread pool implementation, which relies on Environment.ProcessorCount, as opposed to the native thread pool, which uses the affinity mask
- After this change, in affinitized cases on Windows the behavior is consistent perf-wise with Linux in similar situations:
  - The portable thread pool uses the same worker thread count as the native thread pool
  - `Environment.ProcessorCount` returns the number of processors the the process is affinitized to, which may be less than it would have returned before

… (#47284)

* return accurate size for amd dsp and amd dsp+cnst

* fix the condition

…g (#45821)

* Use correct CoreLib configuration for shared framework linker trimming

* Add IL subdir to CoreLib path unconditionally

* Go back to using GetTargetPath, but flow rc to it

* Update CoreLibProject properties only when necessary

* Add link to CoreLib bin-placing issue and update RuntimeConfiguration in comment

* Clean up interop shared data types with the DAC.

* Feedback from preview CR.

* Create specific CRST for the managed object wrapper map.

…… (#42476)

* Added C# implementation of System.Math.ScaleB and System.MathF.ScaleB, removed old bindings, added test cases.

* Moved tests into System.Runtime.Extensions tests.

* Removed unmanaged scalbn and scalbnf from pal and mono

* Update src/libraries/System.Private.CoreLib/src/System/Math.cs

Co-authored-by: Adeel Mujahid <adeelbm@outlook.com>

* Styling changes.

* Conditionally include ScaleB for Mono.

* Update src/mono/mono/metadata/sysmath.c

Tabs, not spaces.

Co-authored-by: Adeel Mujahid <adeelbm@outlook.com>

* Removing more scalb from PAL

* Completely removed ScaleB from Mono

* Cleaning up more scalbn

* Added comments for ScaleB, updated licenses for musl and Sun

* Fixed whitespace.

* Removing old references, fixing double ScaleB definition that merge didn't resolve

Co-authored-by: Adeel Mujahid <adeelbm@outlook.com>

…process (#47253)

We want to use a separate directory for intermediate build outputs, that aren't needed
in the app bundle, and reduce unclear internal dependencies during a build.

# TL;DR

## Changes:
1. `$(WasmBuildDir)` removed
2. Reasonable defaults set for most properties
3. To generate a wasm app for a project, the minimum you need to set:
    a. `$(WasmMainJS)`,
    b. and `@(WasmAssembliesToBundle)`

# Details:

Though it is a bit tricky, because the current targets assume:

- that they are being run after `Publish`
- that the publish directory has:
  - some required files copied over from the runtime pack (eg. `libmono*`),
  - and includes the assemblies
- that the targets emit all the intermediate output files like `driver.o`, or the bitcode files, into the same
   directory

- And there are assumptions about where to pick which files from (eg. whether to take `dotnet.wasm`
  from the runtime pack, or from the publish dir), based on unclear rules.

## What does this PR change?

- All the assets meant to be from the runtime pack (like `libmono*`, `icudt.dat`) are always taken
  only from the runtime pack
  - and this logic is moved out of the tasks, to the targets
- `$(WasmBuildDir)` is removed completely. Instead, we use an intermediate path based on `$(IntermediateOutputPath)`
  - and emit all the intermediate bits there, like the bitcode files
- Add reasonable defaults for various properties, like `$(WasmAppDir)`

Effectively:

1. To generate a wasm app for a project, the minimum you need to set:
    a. `$(WasmMainJS)`,
    b. and `@(WasmAssembliesToBundle)`

2. The targets don't depend on publish dir at all
    (in a future PR, we could remove triggering based on `Publish` target also)
* [wasm] WasmAppBuilder - move the list of native assets, and logic out

.. to the targets.

- New property: `NativeAssets`, populated by `@(WasmNativeAsset)`
- Remove property `MicrosoftNetCoreAppRuntimePackRidDir`
- Also, add the `icudt.dat` file from the targets

* [wasm] Simplify handling of dotnet.{js,wasm}

WasmAppBuilder has (non-obvious) logic to:

1. if AOT'ing, then use the *generated* dotnet.{js,wasm};
2. else use the one from the runtime pack

This depends on Publish having copied those files from the runtime pack
to the publish directory, and then comparing paths in the builder to
decide which one to use.

Instead, make this the intention obvious, and clear.

----
Commits:
* [wasm] Always get the native libs from the runtime pack (eg.libmono*)

We were getting these from the publish directory, instead we can get
them directly from the runtime pack.

This includes icudt.dt, and dotnet.timezones.blat .

* [wasm] MonoAOTCompiler: add `OutputDir` property

.. where we can emit the generated native files. Since these files are
meant only for generating the final `dotnet.wasm`, we don't want them to
put them in the bin directory.

* [wasm] Use existing list of assemblies - @(_WasmAssemblies)

.. instead of trying to find them in the build dir. This build directory
will become a directory for intermediate build output in upcoming
commits.

* [wasm] Replace $(WasmMainAssemblyPath) with $(WasmMainAssemblyFileName)

- Instead of having a special $(WasmMainAssemblyPath), and then adding
  it to the wasm assemblies ourselves
  - let the user project add all the relevant assemblies to
    `@(WasmAssembliesToBundle)`, which is usually as simple as
    `$(OutDir)\*.dll`.

- This helps to simplify lot of things.
- And we just need the main assembly filename for generating the
  run-v8.sh script.

* [wasm] Rename WasmBuildDir -> _WasmIntermediateOutputPath

Based on the changes in previous commits, we can now remove
`$(WasmBuildDir)`, and replace that with an internal
`$(_WasmIntermediateOutputPath)`. This path will have all the build
artifacts generated that aren't required in the app bundle.

Earlier, we were using the publish directory for that, which resulted in
it being littered with unncessary files, and files getting copied to the
app bundle from unclear sources, and for non-obvious reasons.

* [wasm] add default value for $(WasmAppDir)

* [wasm] WasmApp.targets - misc cleanup

* [wasm] WasmAppBuilder: validate Assemblies property

* [wasm] WasmTestRunner - rename TestAssembly->TestAssemblyFileName, to correctly reflect the value

* [wasm] Fix make clean, for samples

* [wasm] WasmApp.targets: Add new $(MonoAotCrossCompilerPath)

* [wasm] update comments/docs

* Address review feedback from @mdh1418

…tes (#47345)

* Resolve ILLink warnings in System.Security.Cryptography.X509Certificates

Contributes to #45623

* Use ConstructorInfo to create HttpRequestMessage instances.

…1 loopback implementation of SendResponseBodyAsync (#47364)

Get rid of StreamWriter usage in HTTP loopback server and fix HTTP/1.1 loopback implementation of SendResponseBodyAsync 

Co-authored-by: Geoffrey Kizer <geoffrek@windows.microsoft.com>

…ding encodings (#47000)

Improve support for user-specified Accept-Encoding encodings


Co-authored-by: Stephen Toub <stoub@microsoft.com>
Co-authored-by: Stephen Toub <stoub@microsoft.com>
Co-authored-by: Stephen Toub <stoub@microsoft.com>

* Debugging Crossgen2 documentation and such
- Also new --print-repro-instructions command line switch to crossgen2 as requested by the JIT team

Create a number of smaller files with cohesive sets of methods.

…cceptWebSocketAsync (#47402)

* Fix #46123 - make `subProtocol` nullable when dealing with WebSockets in HttpListener.

* Update ref for System.Net.HttpListener

* Fix for issue 46529
Move check for side-effect and don't push the cast for shifts of 32 to 63
Added test Runtime_46239.cs

* clang format

<!--
Thank you for your Pull Request!

If you are new to contributing to Mono, please try to do your best at conforming to our coding guidelines http://www.mono-project.com/community/contributing/coding-guidelines/ but don't worry if you get something wrong. One of the project members will help you to get things landed.

Does your pull request fix any of the existing issues? Please use the following format: Fixes #issue-number
-->

Co-authored-by: vargaz <vargaz@users.noreply.github.com>

When `libgdiplus` is installed via macports, `System.TypeInitializationException` exception is thrown.
This is because macports installs the library in `/opt/local/lib`.

```sh
$ port install libgdiplus
$ port contents libgdiplus
Port libgdiplus contains:
  /opt/local/lib/libgdiplus.0.dylib
  /opt/local/lib/libgdiplus.a
  /opt/local/lib/libgdiplus.dylib
  /opt/local/lib/pkgconfig/libgdiplus.pc
  /opt/local/share/doc/libgdiplus/AUTHORS
  /opt/local/share/doc/libgdiplus/COPYING
  /opt/local/share/doc/libgdiplus/ChangeLog
  /opt/local/share/doc/libgdiplus/LICENSE
  /opt/local/share/doc/libgdiplus/NEWS
  /opt/local/share/doc/libgdiplus/README.md
  /opt/local/share/doc/libgdiplus/TODO
```

PR adds `/opt/local/lib/libgdiplus.dylib` as a well-known probing path.

* [wasm] Handle Top-Level style entry point mangling too

This adds a check for '<Main>$' in addition to 'Main' when
looking for the async entry point.

Fixes #47404

* Performance tuning Xoshiro pseudo random number generators. Move PRNG state from the heap onto the stack before performong PRNG generation and mxing operations.

* Declare PRNG state method variables on single line (code review feedback nit).

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

Use a separate thread for tiered compilation background work

- Makes it easier to manage how much time is spend for performing background work like rejitting and allows yielding more frequently with just Sleep without incurring thread pool overhead, which is useful in CPU-limited cases
- A min/max range is determined for how long background work will be done before yielding the thread. The max is the same as before, 50 ms. For now the min is `processor count` ms (capped to the max), such that in CPU-limited cases the thread would yield more frequently in order to not monopolize too much of the limited CPU resources for background work, and in cases with a larger number of processors where the background work is typically less intrusive to foreground work it would yield less frequently.
- At the same time, progress should be made on background work such that steady-state perf would be reached in reasonable time. Yielding too frequently can slow down the background work too much. The sleep duration is measured to identify oversubscribed situations to yield less frequently and make faster progress on the background work.
- Due to less time spent rejitting in some CPU-limited cases, steady-state performance may be reached a bit later in favor of fewer spikes along the way
- When the portable thread pool is enabled, a side effect of using a managed worker thread for tiering background work was that several GC-heavy microbenchmarks regressed. Tiering was the only thing using the thread pool in those tests and stack-walking the managed thread was slower due to the presence of GC refs. It's not too concerning, the benchmarks are just measuring something different from before, but in any case this change also resolves that issue. Fixes dotnet/runtime#44211.

Fixes #47426

…erge