sync non-code with origin/main (#7736)

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

.github/learning-path-sha.txt

@@ -1 +1 @@
-17b6501236d7069e11dec7cf27bdb33a776214c6
+5c9333c5ba22099d6d4ab86583f3f1b1bb586851

.github/workflows/submit-to-do-issue.yml

@@ -35,7 +35,7 @@ jobs:
       # The default artifact download action doesn't support cross-workflow
       # artifacts, so use a 3rd party one.
       - name: 'Download linting results'
-        uses: dawidd6/action-download-artifact@bf251b5aa9c2f7eeb574a96ee720e24f801b7c11
+        uses: dawidd6/action-download-artifact@80620a5d27ce0ae443b965134db88467fc607b43
         with:
           workflow: ${{env.workflow_name}}
           run_id: ${{github.event.workflow_run.id }}

documentation/learningPath/aks.md

@@ -6,7 +6,7 @@ In addition to its availability as a .NET CLI tool, the `dotnet monitor` tool is
 
 This workflow takes your local development copy of `dotnet-monitor`, patches it with a local development copy of the [.NET Core Diagnostics Repo](https://github.com/dotnet/diagnostics#net-core-diagnostics-repo), and makes it available as an image for you to consume in an ACR (Azure Container Registry). Note that there are many other ways to do this - this is meant to serve as a basic template that can be adapted to match your needs.
 
-1. Open `pwsh` and run the [generate-dev-sln script](https://github.com/dotnet/dotnet-monitor/blob/17b6501236d7069e11dec7cf27bdb33a776214c6/generate-dev-sln.ps1), providing a path to your local copy of the diagnostics repo.
+1. Open `pwsh` and run the [generate-dev-sln script](https://github.com/dotnet/dotnet-monitor/blob/5c9333c5ba22099d6d4ab86583f3f1b1bb586851/generate-dev-sln.ps1), providing a path to your local copy of the diagnostics repo.
 
 > [!NOTE]
 > If your changes do not involve the [.NET Core Diagnostics Repo](https://github.com/dotnet/diagnostics#net-core-diagnostics-repo), you don't need to complete this step.

documentation/learningPath/api.md

@@ -4,15 +4,15 @@ dotnet-monitor exposes functionality through both [collection rules](./collectio
 
 ## Adding New APIs
 
-The web API surface is defined by a series of controllers [here](https://github.com/dotnet/dotnet-monitor/blob/17b6501236d7069e11dec7cf27bdb33a776214c6/src/Microsoft.Diagnostics.Monitoring.WebApi/Controllers/). It's common for an API to expose functionality also available via [Actions](./collectionrules.md#actions) and so methods in these controllers are often wrappers around a shared implementation. Each controller may have one or more attributes that configure how and where it is exposed, you can learn more about the notable controller attributes [here](#notable-controller-attributes).
+The web API surface is defined by a series of controllers [here](https://github.com/dotnet/dotnet-monitor/blob/5c9333c5ba22099d6d4ab86583f3f1b1bb586851/src/Microsoft.Diagnostics.Monitoring.WebApi/Controllers/). It's common for an API to expose functionality also available via [Actions](./collectionrules.md#actions) and so methods in these controllers are often wrappers around a shared implementation. Each controller may have one or more attributes that configure how and where it is exposed, you can learn more about the notable controller attributes [here](#notable-controller-attributes).
 
-If the new API needs to either accept or return structured data, a dedicated model should be used. Models are defined [here](https://github.com/dotnet/dotnet-monitor/blob/17b6501236d7069e11dec7cf27bdb33a776214c6/src/Microsoft.Diagnostics.Monitoring.WebApi/Models/).
+If the new API needs to either accept or return structured data, a dedicated model should be used. Models are defined [here](https://github.com/dotnet/dotnet-monitor/blob/5c9333c5ba22099d6d4ab86583f3f1b1bb586851/src/Microsoft.Diagnostics.Monitoring.WebApi/Models/).
 
 When adding a new API, it's important to also update the [`openapi.json`](../openapi.json) spec which describes the API surface. There are CI tests that will ensure this file has been updated to reflect any API changes. Learn more about updating `openapi.json` [here](./testing.md#openapi-generation).
 
 ### Adding Tests
 
-Web APIs in dotnet-monitor are typically tested using functional tests that leverage the [ApiClient](https://github.com/dotnet/dotnet-monitor/blob/17b6501236d7069e11dec7cf27bdb33a776214c6/src/Tests/Microsoft.Diagnostics.Monitoring.Tool.FunctionalTests/HttpApi/ApiClient.cs) to call a specific API. Learn more about how the functional tests are defined and operate [here](./testing.md#functional-tests).
+Web APIs in dotnet-monitor are typically tested using functional tests that leverage the [ApiClient](https://github.com/dotnet/dotnet-monitor/blob/5c9333c5ba22099d6d4ab86583f3f1b1bb586851/src/Tests/Microsoft.Diagnostics.Monitoring.Tool.FunctionalTests/HttpApi/ApiClient.cs) to call a specific API. Learn more about how the functional tests are defined and operate [here](./testing.md#functional-tests).
 
 ## Notable Controller Attributes
 
@@ -32,6 +32,6 @@ dotnet-monitor supports multiple different [authentication modes](../authenticat
 
 ### Determining Authentication Mode
 
-When dotnet-monitor starts, the command line arguments are first inspected to see if a specific authentication mode was set (such as `--no-auth`), referred to as the `StartupAuthenticationMode`, this is calculated [here](https://github.com/dotnet/dotnet-monitor/blob/17b6501236d7069e11dec7cf27bdb33a776214c6/src/Tools/dotnet-monitor/Commands/CollectCommandHandler.cs#L28). If no modes were explicitly set via a command line argument, dotnet-monitor will select `Deferred` as the `StartupAuthenticationMode`. This indicates that the user configuration should be looked at to determine the authentication mode later on in the startup process.
+When dotnet-monitor starts, the command line arguments are first inspected to see if a specific authentication mode was set (such as `--no-auth`), referred to as the `StartupAuthenticationMode`, this is calculated [here](https://github.com/dotnet/dotnet-monitor/blob/5c9333c5ba22099d6d4ab86583f3f1b1bb586851/src/Tools/dotnet-monitor/Commands/CollectCommandHandler.cs#L28). If no modes were explicitly set via a command line argument, dotnet-monitor will select `Deferred` as the `StartupAuthenticationMode`. This indicates that the user configuration should be looked at to determine the authentication mode later on in the startup process.
 
-After determining the `StartupAuthenticationMode` mode, the relevant [IAuthenticationConfigurator](https://github.com/dotnet/dotnet-monitor/blob/17b6501236d7069e11dec7cf27bdb33a776214c6/src/Tools/dotnet-monitor/Auth/IAuthenticationConfigurator.cs) is created by the [AuthConfiguratorFactory](https://github.com/dotnet/dotnet-monitor/blob/17b6501236d7069e11dec7cf27bdb33a776214c6/src/Tools/dotnet-monitor/Auth/AuthConfiguratorFactory.cs). This factory also handles deciding what authentication mode to use when `StartupAuthenticationMode` is `Deferred`. The selected configurator is used to configure various parts of dotnet-monitor that are specific to authentication, such as protecting the web APIs and adding authentication-mode specific logging.
+After determining the `StartupAuthenticationMode` mode, the relevant [IAuthenticationConfigurator](https://github.com/dotnet/dotnet-monitor/blob/5c9333c5ba22099d6d4ab86583f3f1b1bb586851/src/Tools/dotnet-monitor/Auth/IAuthenticationConfigurator.cs) is created by the [AuthConfiguratorFactory](https://github.com/dotnet/dotnet-monitor/blob/5c9333c5ba22099d6d4ab86583f3f1b1bb586851/src/Tools/dotnet-monitor/Auth/AuthConfiguratorFactory.cs). This factory also handles deciding what authentication mode to use when `StartupAuthenticationMode` is `Deferred`. The selected configurator is used to configure various parts of dotnet-monitor that are specific to authentication, such as protecting the web APIs and adding authentication-mode specific logging.