Update doc links and reduce redirects (#2137)

* Update links

* Fix formatting

* http -> https, docs.microsoft -> learn.microsoft

* learn.microsoft.com/en-us/ -> learn.microsoft.com/

* remove brackets because the site adds whitespaces around them (markdown doesn't do it)

* revert whitespaces and put it inside markdown block

Author: YegorStepanov

docs/_changelog/footer/v0.10.7.md

@@ -2,7 +2,7 @@ _Date: June 05, 2017_
 
 _Milestone: [v0.10.7](https://github.com/PerfDotNet/BenchmarkDotNet/issues?q=milestone%3Av0.10.7)_
 
-_Overview post: http://aakinshin.net/blog/post/bdn-v0_10_7/_
+_Overview post: https://aakinshin.net/posts/bdn-v0_10_7/_
 
 _NuGet Packages:_
 * https://www.nuget.org/packages/BenchmarkDotNet/0.10.7

docs/_changelog/header/v0.10.10.md

@@ -1,10 +1,10 @@
 Highlights:
 
-* Disassembly Diagnoser (read more here: [Disassembling .NET Code with BenchmarkDotNet](http://adamsitnik.com/Disassembly-Diagnoser/))
+* Disassembly Diagnoser (read more here: [Disassembling .NET Code with BenchmarkDotNet](https://adamsitnik.com/Disassembly-Diagnoser/))
 * ParamsSources
 * .NET Core x86 support
 * Environment variables and Mono args support
 * Better environment description
 * More: additional sections in the documentation, bug fixes, build script improvements, internal refactoring.
 
-Overview post: [BenchmarkDotNet v0.10.10](http://aakinshin.net/blog/post/bdn-v0_10_10/)
+Overview post: [BenchmarkDotNet v0.10.10](https://aakinshin.net/posts/bdn-v0_10_10/)

docs/_changelog/header/v0.10.12.md

@@ -1,4 +1,4 @@
-Overview post: [BenchmarkDotNet v0.10.12](http://aakinshin.net/blog/post/bdn-v0_10_12/)
+Overview post: [BenchmarkDotNet v0.10.12](https://aakinshin.net/posts/bdn-v0_10_12/)
 
 ### Highlights
 

docs/_changelog/header/v0.10.13.md

@@ -1 +1 @@
-Overview post: [BenchmarkDotNet v0.10.13](http://aakinshin.net/blog/post/bdn-v0_10_13/)
+Overview post: [BenchmarkDotNet v0.10.13](https://aakinshin.net/posts/bdn-v0_10_13/)

docs/_changelog/header/v0.10.14.md

@@ -1,4 +1,4 @@
-* Per-method parameterization ([Read more](http://benchmarkdotnet.org/Advanced/Arguments.htm))
+* Per-method parameterization ([Read more](https://benchmarkdotnet.org/articles/features/parameterization.html))
 * Console histograms and multimodal disribution detection
-* Many improvements for Mono disassembly support on Windows ([Read more](https://aakinshin.net/blog/post/dotnet-crossruntime-disasm/))
+* Many improvements for Mono disassembly support on Windows ([Read more](https://aakinshin.net/posts/dotnet-crossruntime-disasm/))
 * Many bugfixes

docs/_changelog/header/v0.11.2.md

@@ -45,7 +45,7 @@ In this release, we have many improvements in different areas:
 
 ### EtwProfiler
 
-`EtwProfiler` allows to profile the benchmarked .NET code on Windows and exports the data to a trace file which can be opened with [PerfView](https://github.com/Microsoft/perfview) or [Windows Performance Analyzer](https://docs.microsoft.com/en-us/windows-hardware/test/wpt/windows-performance-analyzer).
+`EtwProfiler` allows to profile the benchmarked .NET code on Windows and exports the data to a trace file which can be opened with [PerfView](https://github.com/Microsoft/perfview) or [Windows Performance Analyzer](https://learn.microsoft.com/windows-hardware/test/wpt/windows-performance-analyzer).
 
 `EtwProfiler` uses `TraceEvent` library which internally uses Event Tracing for Windows (ETW) to capture stack traces and important .NET Runtime events.
 Before the process with benchmarked code is started, EtwProfiler starts User and Kernel ETW sessions. Every session writes data to it's own file and captures different data. User session listens for the .NET Runtime events (GC, JIT etc) while the Kernel session gets CPU stacks and Hardware Counter events. After this, the process with benchmarked code is started. During the benchmark execution all the data is captured and written to a trace file. Moreover, BenchmarkDotNet Engine emits it's own events to be able to differentiate jitting, warmup, pilot and actual workload when analyzing the trace file. When the benchmarking is over, both sessions are closed and the two trace files are merged into one.
@@ -116,7 +116,7 @@ Now it's possible to run benchmarks on preview versions of .NET Core 3.0.
 
 ### Deferred Execution Validator
 
-In LINQ, execution of a query is usually [deferred](https://blogs.msdn.microsoft.com/charlie/2007/12/10/linq-and-deferred-execution/) until the moment when you actually request the data. If your benchmark just returns `IEnumerable` or `IQueryable` it's not measuring the execution of the query, just the creation.
+In LINQ, execution of a query is usually [deferred](https://learn.microsoft.com/dotnet/standard/linq/deferred-execution-example) until the moment when you actually request the data. If your benchmark just returns `IEnumerable` or `IQueryable` it's not measuring the execution of the query, just the creation.
 
 This is why we decided to warn you about this issue whenever it happens:
 

docs/_changelog/header/v0.11.3.md

@@ -23,9 +23,9 @@ This release is focused mainly on bug fixes that were affecting user experience.
 
 ### ConcurrencyVisualizerProfiler
 
-`ConcurrencyVisualizerProfiler` allows to profile the benchmarked .NET code on Windows and exports the data to a CVTrace file which can be opened with [Concurrency Visualizer](https://docs.microsoft.com/en-us/visualstudio/profiling/concurrency-visualizer).
+`ConcurrencyVisualizerProfiler` allows to profile the benchmarked .NET code on Windows and exports the data to a CVTrace file which can be opened with [Concurrency Visualizer](https://learn.microsoft.com/visualstudio/profiling/concurrency-visualizer).
 
-`ConcurrencyVisualizerProfiler` uses `EtwProfiler` to get a `.etl` file which still can be opened with [PerfView](https://github.com/Microsoft/perfview) or [Windows Performance Analyzer](https://docs.microsoft.com/en-us/windows-hardware/test/wpt/windows-performance-analyzer). The difference is that it also enables all Task and Thread related ETW Providers and exports a simple `xml` which can be opened with Visual Studio if you install [Concurrency Visualizer plugin](https://marketplace.visualstudio.com/items?itemName=Diagnostics.ConcurrencyVisualizer2017)
+`ConcurrencyVisualizerProfiler` uses `EtwProfiler` to get a `.etl` file which still can be opened with [PerfView](https://github.com/Microsoft/perfview) or [Windows Performance Analyzer](https://learn.microsoft.com/windows-hardware/test/wpt/windows-performance-analyzer). The difference is that it also enables all Task and Thread related ETW Providers and exports a simple `xml` which can be opened with Visual Studio if you install [Concurrency Visualizer plugin](https://marketplace.visualstudio.com/items?itemName=Diagnostics.ConcurrencyVisualizer2017)
 
 ![open trace](https://user-images.githubusercontent.com/6011991/48638184-2b13fe00-e9d0-11e8-8a94-0e951e4606ae.png)
 

docs/_changelog/header/v0.12.0.md

@@ -216,8 +216,8 @@ Full .NET Framework always runs every .NET executable using the latest .NET Fram
 If you try to run the benchmarks for a few .NET TFMs, they are all going to be executed using the latest .NET Framework from your machine.
 The only difference is that they are all going to have different features enabled depending on the target version they were compiled for.
 You can read more about this
-  [here](https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/version-compatibility) and
-  [here](https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/application-compatibility).
+  [here](https://learn.microsoft.com/dotnet/framework/migration-guide/version-compatibility) and
+  [here](https://learn.microsoft.com/dotnet/framework/migration-guide/application-compatibility).
 This is **.NET Framework behavior which can not be controlled by BenchmarkDotNet or any other tool**.
 
 **Note:** Console arguments support works only if you pass the `args` to `BenchmarkSwitcher`:
@@ -282,7 +282,7 @@ Moreover, if you share the source code of the benchmark, other people can run it
 ## Official templates for BenchmarkDotNet-based projects
 
 Since v0.12.0, BenchmarkDotNet provides project templates to setup your benchmarks easily.
-The template exists for each major .NET language ([C#](https://docs.microsoft.com/en-us/dotnet/csharp/), [F#](https://docs.microsoft.com/en-us/dotnet/fsharp/) and [VB](https://docs.microsoft.com/en-us/dotnet/visual-basic/)) with equivalent features and structure.
+The template exists for each major .NET language ([C#](https://learn.microsoft.com/dotnet/csharp/), [F#](https://learn.microsoft.com/dotnet/fsharp/) and [VB](https://learn.microsoft.com/dotnet/visual-basic/)) with equivalent features and structure.
 The templates require the [.NET Core SDK](https://www.microsoft.com/net/download). Once installed, run the following command to install the templates:
 
 ```log
@@ -352,7 +352,7 @@ dotnet new benchmark --help
 
 The version of the template NuGet package is synced with the [BenchmarkDotNet](https://www.nuget.org/packages/BenchmarkDotNet/) package.
 For instance, the template version `0.12.0` is referencing [BenchmarkDotnet 0.12.0](https://www.nuget.org/packages/BenchmarkDotNet/0.12.0) - there is no floating version behavior.
-For more info about the `dotnet new` CLI, please read [the documentation](https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet).
+For more info about the `dotnet new` CLI, please read [the documentation](https://learn.microsoft.com/dotnet/core/tools/dotnet).
 
 ## New NativeMemoryProfiler
 

docs/_changelog/header/v0.13.2.md

@@ -56,7 +56,7 @@ We are really excited to see the experimental CoreRT project grow and become off
 As every AOT solution, NativeAOT has some [limitations](https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/docs/limitations.md) like limited reflection support or lack of dynamic assembly loading. Because of that, the host process (what you run from command line) is never an AOT process, but just a regular .NET process. This process (called Host process) uses reflection to read benchmarks metadata (find all `[Benchmark]` methods etc.), generates a new project that references the benchmarks and compiles it using ILCompiler. The boilerplate code is not using reflection, so the project is built with `TrimmerDefaultAction=link` (we have greatly reduced build time thanks to that). Such compilation produces a native executable, which is later started by the Host process. This process (called Benchmark or Child process) performs the actual benchmarking and reports the results back to the Host process. By default BenchmarkDotNet uses the latest version of `Microsoft.DotNet.ILCompiler` to build the NativeAOT benchmark according to [this instructions](https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/docs/compiling.md). Moreover, BenchmarkDotNet by default uses current machines CPU features (change: [#1994](https://github.com/dotnet/BenchmarkDotNet/pull/1994), discussion: [#2061](https://github.com/dotnet/BenchmarkDotNet/issues/2061)) and if you don't like this behavior, you can [disable it](https://github.com/dotnet/BenchmarkDotNet/issues/2061#issuecomment-1203602177).
 
 This is why you need to:
-- install [pre-requisites](https://docs.microsoft.com/en-us/dotnet/core/deploying/native-aot/#prerequisites) required by NativeAOT compiler
+- install [pre-requisites](https://learn.microsoft.com/dotnet/core/deploying/native-aot/#prerequisites) required by NativeAOT compiler
 - target .NET to be able to run NativeAOT benchmarks (example: `<TargetFramework>net7.0</TargetFramework>` in the .csproj file)
 - run the app as a .NET process (example: `dotnet run -c Release -f net7.0`).
 - specify the NativeAOT runtime in an explicit way, either by using console line arguments `--runtimes nativeaot7.0` (the recommended approach), or by using`[SimpleJob]` attribute or by using the fluent Job config API `Job.ShortRun.With(NativeAotRuntime.Net70)`:

docs/articles/configs/diagnosers.md

@@ -10,7 +10,7 @@ A **diagnoser** can attach to your benchmark and get some useful info.
 The current Diagnosers are:
 
 - GC and Memory Allocation (`MemoryDiagnoser`) which is cross platform, built-in and **is not enabled by default anymore**.
-  Please see Adam Sitnik's [blog post](http://adamsitnik.com/the-new-Memory-Diagnoser/) for all the details.
+  Please see Adam Sitnik's [blog post](https://adamsitnik.com/the-new-Memory-Diagnoser/) for all the details.
 - JIT Inlining Events (`InliningDiagnoser`).
   You can find this diagnoser in a separate package with diagnosers for Windows (`BenchmarkDotNet.Diagnostics.Windows`):
   [![NuGet](https://img.shields.io/nuget/v/BenchmarkDotNet.svg)](https://www.nuget.org/packages/BenchmarkDotNet.Diagnostics.Windows/)
@@ -20,10 +20,10 @@ The current Diagnosers are:
 - Hardware Counter Diagnoser.
   You can find this diagnoser in a separate package with diagnosers for Windows (`BenchmarkDotNet.Diagnostics.Windows`):
   [![NuGet](https://img.shields.io/nuget/v/BenchmarkDotNet.svg)](https://www.nuget.org/packages/BenchmarkDotNet.Diagnostics.Windows/).
-  Please see Adam Sitnik's [blog post](http://adamsitnik.com/Hardware-Counters-Diagnoser/) for all the details.
+  Please see Adam Sitnik's [blog post](https://adamsitnik.com/Hardware-Counters-Diagnoser/) for all the details.
 - Disassembly Diagnoser.
   It allows you to disassemble the benchmarked code to asm, IL and C#/F#.
-  Please see Adam Sitnik's [blog post](http://adamsitnik.com/Disassembly-Diagnoser/) for all the details.
+  Please see Adam Sitnik's [blog post](https://adamsitnik.com/Disassembly-Diagnoser/) for all the details.
 - ETW Profiler (`EtwProfiler`).
   It allows you to not only benchmark, but also profile the code. It's using TraceEvent, which internally uses ETW and exports all the information to a trace file. The trace file contains all of the stack traces captured by the profiler, PDBs to resolve symbols for both native and managed code and captured GC, JIT and CLR events. Please use one of the free tools: PerfView or Windows Performance Analyzer to analyze and visualize the data from trace file. You can find this diagnoser in a separate package with diagnosers for Windows (`BenchmarkDotNet.Diagnostics.Windows`): [![NuGet](https://img.shields.io/nuget/v/BenchmarkDotNet.svg)](https://www.nuget.org/packages/BenchmarkDotNet.Diagnostics.Windows/)
   Please see Adam Sitnik's [blog post](https://adamsitnik.com/ETW-Profiler/) for all the details.
@@ -80,7 +80,7 @@ In BenchmarkDotNet, 1kB = 1024B, 1MB = 1024kB, and so on. The column Gen X means
 
 * In order to not affect main results we perform a separate run if any diagnoser is used. That's why it might take more time to execute benchmarks.
 * MemoryDiagnoser:
-	* Mono currently [does not](http://stackoverflow.com/questions/40234948/how-to-get-the-number-of-allocated-bytes-in-mono) expose any api to get the number of allocated bytes. That's why our Mono users will get `?` in Allocated column.
+	* Mono currently [does not](https://stackoverflow.com/questions/40234948/how-to-get-the-number-of-allocated-bytes-in-mono) expose any api to get the number of allocated bytes. That's why our Mono users will get `?` in Allocated column.
 	* In order to get the number of allocated bytes in cross platform way we are using `GC.GetAllocatedBytesForCurrentThread` which recently got [exposed](https://github.com/dotnet/corefx/pull/12489) for netcoreapp1.1. That's why BenchmarkDotNet does not support netcoreapp1.0 from version 0.10.1.
 	* MemoryDiagnoser is `99.5%` accurate about allocated memory when using default settings or Job.ShortRun (or any longer job than it).
 * Threading Diagnoser: