Host ID collision error should be a diagnostic event

[paulbatum]

For background on hostID collision see:
https://github.com/Azure/azure-functions-host/wiki/Host-IDs

Repro steps

1. Create two function apps with a deliberate host ID collision, e.g. make them share a storage account and have a name that is longer than 32 characters.
2. Restart the apps once they are both created, to force the collision check to occur

Expected behavior

One or both the apps should fail to start with the collision error e.g. A collision for Host ID 'asdf' was detected in the configured storage account. For more information, see https://aka.ms/functions-hostid-collision.

This error should be displayed in the portal, as an error banner. Most importantly, the link in the above error message needs to be rendered so that the user can follow it and take the recommended actions. For this to happen, it needs to be logged as a diagnostic event.

Actual behavior

No mention of host ID truncation appears in the portal experience. The user has to go to detailed logs such as app insights to find the details of the truncation error. They may see other error noise that is just a symptom, of the host shutting down to the collision, such as the below message, but this won't lead them to understanding the root of the problem.

2022-12-01T23:26:41.158 [Error] Failed to start a new language worker for runtime: dotnet-isolated.
System.Threading.Tasks.TaskCanceledException : A task was canceled.
   at async Microsoft.Azure.WebJobs.Script.Grpc.GrpcWorkerChannel.StartWorkerProcessAsync(CancellationToken cancellationToken) at /_/src/WebJobs.Script.Grpc/Channel/GrpcWorkerChannel.cs : 271
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

[asalvo]

This feature would have saved us several days. In our case, we were using an incorrect casing of AzureFunctionsWebHost__hostid to specify a custom Host Id (we had Id instead of id), so we were getting host id collisions.

However, we saw this log line "Host id explicitly set in configuration. This is not a recommended configuration and may lead to unexpected behavior." which implies that our hostId setting was being used. There were no errors logged indicated there was a hostId collision.

[asalvo]

There is also a lot of confusion over the casing of hostid vs hostId in the context of the Diagnostics error. See the recent comments (including my own) over here: #2015 (comment)

[scp-mb]

+1 on this, spent time tracking down why we were getting TaskCanceledException seemingly randomly as no error message was present.