Remove await Task.FromResult() and unnecessary async modifiers

[ronaldbarendse]

Prerequisites

• I have added steps to test this contribution in the description below

Description

While working on another fix, I noticed we have quite a few occurrences of await Task.FromResult() (as mentioned in #16430 (comment)). This indicates a real anti-pattern, as you would only need Task.FromResult() when you don't need to use await in an async method (if all work is synchronous, but your method signature is still async and returns an awaitable task). And if all work in the method is synchronous, you don't need to mark it as async, as that will cause the C# compiler to unnecessarily generate a state machine, see: https://learn.microsoft.com/en-us/dotnet/csharp/asynchronous-programming/async-scenarios#important-info-and-advice.

Removing the async keyword from a method doesn't change the signature, so all those changes in this PR will only cause the compiler to emit less code (which results is smaller assemblies and faster execution).

Another (Umbraco specific) anti-pattern is to use Task.WhenAll() when doing work that creates Umbraco scopes, as the created scopes need to be disposed in the correct/reverse order they were created or otherwise suppress the execution scope (so new root scopes are created instead):

Umbraco-CMS/src/Umbraco.Infrastructure/Scoping/Scope.cs

Line 367 in d1aac39

$"The {nameof(Scope)} {InstanceId} being disposed is not the Ambient {nameof(Scope)} {_scopeProvider.AmbientScope?.InstanceId.ToString() ?? "NULL"}. This typically indicates that a child {nameof(Scope)} was not disposed, or flowed to a child thread that was not awaited, or concurrent threads are accessing the same {nameof(Scope)} (Ambient context) which is not supported. If using Task.Run (or similar) as a fire and forget tasks or to run threads in parallel you must suppress execution context flow with ExecutionContext.SuppressFlow() and ExecutionContext.RestoreFlow().";

I've updated most of these cases, although some will now not execute the tasks in parallel anymore. But it's better to not risk the chance of scopes being disposed out of order and throwing exception or getting deadlocks, and take the penalty of a slight decrease in performance instead.

Testing will mostly be validating the code changes and ensuring the build and tests run as expected, as there's really not a lot of functional changes in this PR 🤓

[ronaldbarendse]

By using a method that returns IAsyncEnumerable, we're able to asynchronously iterate over the items by using await foreach (var item in MapTreeItemViewModelsAsync(...)), await MapTreeItemViewModelsAsync(...).ToArrayAsync() or any other To...Async() methods...

[ronaldbarendse]

Even better would be to actually return the IAsyncEnumerable as model (when possible), because that will avoid loading all items into memory and JSON serialize each item one by one.

[ronaldbarendse]

This previously started all tasks at the same time, but uses the ILocalizedTextService to lookup translations (and any Umbraco specific code, especially services, can create scopes). This could be rewritten to do the actual work concurrently and get nicely formatted health check status messages afterwards, but that might be something for later/another PR.

[AndyButland]

Have reviewed and smoke tested, and seems good, but it's a lot of changes. I don't think it's particularly risky but minded to retarget to v16/dev and merge in there, just as there's no rush, and so we have it in a version with a longer testing period.