Merging internal commits for release/6.0

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

 build 20220504.3

Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk
 From Version 6.0.0-beta.22212.5 -> To Version 6.0.0-beta.22254.3

* Harden another shadow copy test (#37083)

* Backport HttpLogging test fixes

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Hao Kung <HaoK@users.noreply.github.com>
Co-authored-by: Will Godbe <wigodbe@microsoft.com>

Bumps [src/submodules/googletest](https://github.com/google/googletest) from `af29db7` to `8ded48c`.
- [Release notes](https://github.com/google/googletest/releases)
- [Commits](https://github.com/google/googletest/compare/af29db7ec28d6df1c7f0f745186884091e602e07...8ded48c37be09d8cc3665af1b414c5d53c0862e7

)

---
updated-dependencies:
- dependency-name: src/submodules/googletest
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Fix yarn alerts

* Fix nuget alerts

* No yarn-audit-fix

* Remove yarn-audit-fix

[internal/release/6.0] Update dependencies from dnceng/internal/dotnet-efcore dnceng/internal/dotnet-runtime

 - Updated helix.proj to IsPublicRuntime=false

- reenable baseline validation
- update 3.1 runtime
- update downlevel site extension versions
- set `$(IsPublicRuntime)` back to `true`

Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk
 From Version 6.0.0-beta.22206.7 -> To Version 6.0.0-beta.22212.5

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

* [internal/release/6.0] Update dependencies from dnceng/internal/dotnet-efcore

* [internal/release/6.0] Update dependencies from dnceng/internal/dotnet-efcore

* [internal/release/6.0] Update dependencies from dnceng/internal/dotnet-efcore

* [internal/release/6.0] Update dependencies from dnceng/internal/dotnet-runtime

* Merged PR 21649: [internal/release/6.0] Make UseUrls() override default hosting config

## Description

Prior to this change, default config (typically loaded from `DOTNET_`/`ASPNET_` environment variables and command line arguments) could override the application-level configuration. This would prevent `GenericWebHostService` from seeing the latest configuration set by `UseUrls()` of `DOTNET_URLS`, `ASPNET_URLS` or `--urls` was set.

Fixes #38185

## Customer Impact

This is a big gotcha to customers using `WebApplicationBuilder` (which is used in all the ASP.NET Core 6 templates) who expect the following to work:

```C#
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.UseUrls("http://*:8080");
var app = builder.Build();
app.Run();
```

A comment on the issue suggesting we patch this has gotten 5 thumbs ups not counting mine.

## Regression?

- [ ] Yes
- [x] No

## Risk

- [ ] High
- [ ] Medium
- [x] Low

This is a small well tested change which only affects the loading of default config sources and those added via a `HostFactoryResolver` to host configuration. [Here’s the existing test](https://github.com/dotnet/aspnetcore/blob/0f6f649f1da658bbe37b8898df0c80c5affa9d2d/src/DefaultBuilder/test/Microsoft.AspNetCore.Tests/WebApplicationTests.cs#L883) showing that the expected configuration providers are still dispose.

## Verification

- [x] Manual (required)
- [x] Automated

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [x] N/A

* [internal/release/6.0] Update dependencies from dnceng/internal/dotnet-runtime

* Merge from github release/6.0

* [internal/release/6.0] Update dependencies from dnceng/internal/dotnet-efcore dnceng/internal/dotnet-runtime

 - Set to private runtime

* Merged PR 21869: Correct `--architecture` in `fpm` commands

# {PR title}

Correct `--architecture` in `fpm` commands

## Description

Update `fpm` commands to use a supported `--architecture` value. As-is, the x64 .rpm files we produce are incompatible w/ installation on an x64 machine. Problem found during servicing version flow.

## Customer Impact

Unable to build dotnet-installer-ci-official w/ current .rpm files from dotnet-aspnetcore repo.

## Regression?

- [x] Yes
- [ ] No

This is a build regression since 6.0.3. It will also impact our 'main' branch.

## Risk

- [ ] High
- [ ] Medium
- [x] Low

Have verified the chosen values for the command line using available online documentation. Since we know the current .rpm files are busted, things can only get better 

## Verification

- [x] Manual (required)
- [ ] Automated

I am locally building this branch and will use `rpmlint` in a `docker` container to verify the goodness of the produced package.

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [ ] N/A

Not sure how to answer this because the change is to an internal setting of the RPM installer. If others agree it's the right change, it's been reviewed 



----

## When servicing release/2.1

- [ ] Make necessary changes in eng/PatchConfig.props

* Merged PR 21931: Revert "[release/6.0] Build ProjectTemplates in Source-Build (#40650)" (#40805)

# {PR title}

Summary of the changes (Less than 80 chars)

## Description

{Detail}

Fixes #{bug number} (in this specific format)

## Customer Impact

{Justification}

## Regression?

- [ ] Yes
- [ ] No

[If yes, specify the version the behavior has regressed from]

## Risk

- [ ] High
- [ ] Medium
- [ ] Low

[Justify the selection above]

## Verification

- [ ] Manual (required)
- [ ] Automated

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [ ] N/A

----

## When servicing release/2.1

- [ ] Make necessary changes in eng/PatchConfig.props

Revert "[release/6.0] Build ProjectTemplates in Source-Build (#40650)" (#40805)

This reverts commit 7c2000d3.

Co-authored-by: dotnet-bot <dotnet-bot@microsoft.com>
Co-authored-by: DotNet Bot <dn-bot@microsoft.com>
Co-authored-by: Stephen Halter <shalter@microsoft.com>
Co-authored-by: mmitche <mmitche@microsoft.com>
Co-authored-by: Doug Bunting (AAPT) <dougbu@microsoft.com>

Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk
 From Version 6.0.0-beta.22178.5 -> To Version 6.0.0-beta.22206.7

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

# ASP.Net FormFeature.cs - DenialOfService

When parsing multi-part form data with FormFeature.cs, we do not honor ValueCountLimit when the content disposition is of an unknown type. Therefore an attacker could send multi-part form data where very part has invalid content disposition, and make us read indefinitely.

## Description

When parsing multi-part form data with FormFeature.cs, we do not honor ValueCountLimit when the content disposition is of an unknown type. Therefore an attacker could send multi-part form data where very part has invalid content disposition, and make us read indefinitely.

## Customer Impact

Prevents a potential Denial-of-service attack.

## Regression?

- [ ] Yes
- [x] No

## Risk

- [ ] High
- [x] Medium
- [ ] Low

We could have missed another potential version of this vulnerability

## Verification

- [x] Manual (required)
- [x] Automated

Added a test, plus confirmed with a local repro that the pre-existing slowdown goes away after the change.

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [x] N/A

----

## When servicing release/2.1

- [ ] Make necessary changes in eng/PatchConfig.props

# Fix partial chunked cookies

MSRC # 70242: Fix exceptions and allocations when the cookie chunk count is not accurate

## Description

Browsers have limits on how long cookies can be, as low as 4kb. It's common for TempData and CookieAuth to get above that limit, so cookies are split into chunks with the following format:

MyCookie=chunks-3
MyCookieC1=(Base64EncodedData)
MyCookieC2=(Base64EncodedData)
MyCookieC3=(Base64EncodedData)

Fixes MSRC # 70242

## Customer Impact

A malicious client could send `MyCookie=chunks-2147483647` without the actual cookie chunks and cause large allocations, exceptions, and excess CPU utilization on the server when it tried to read or delete that many chunks.

This flaw comes from the original implementation in Microsoft.Owin, but is much worse in AspNetCore when adopted by TempData due to it automatically calling Delete if reading the cookie fails.

I'll backport this to 5.0, 3.1, 2.1, and Microsoft.Owin once reviewed.

## Regression?

- [ ] Yes
- [x] No

## Risk

- [ ] High
- [ ] Medium
- [x] Low

Easy to reproduce and test.

## Verification

- [x] Manual (required)
- [x] Automated

## Packaging changes reviewed?

- [ ] Yes
- [ ] No
- [x] N/A

* Add option to project templates to use Program.Main instead of top-level statements (#40886)

Fixes #40944

* Update spa templates submodule

* [release/6.0] Add RID to targeting pack archive names
* Fixup

Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Helix.Sdk
 From Version 6.0.0-beta.22161.1 -> To Version 6.0.0-beta.22178.5

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

Bumps [src/submodules/googletest](https://github.com/google/googletest) from `c9461a9` to `af29db7`.
- [Release notes](https://github.com/google/googletest/releases)
- [Commits](https://github.com/google/googletest/compare/c9461a9b55ba954df0489bab6420eb297bed846b...af29db7ec28d6df1c7f0f745186884091e602e07

)

---
updated-dependencies:
- dependency-name: src/submodules/googletest
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>