Start pre-creating runspaces on function load request

[AnatoliB]

Problem

Creating and initializing a PowerShell runspace (potentially involving profile.ps1 invocation) may take long time (for example, because of a Connect-AzAccount call). This is perceived as a cold start issue affecting even apps on Premium and App Service plans. Resolving just #453 will solve the problem for the first invocation per worker. However, when PSWorkerInProcConcurrencyUpperBound is set to anything more than 1, new runspaces are created and initialized only when actually required (i.e. a function is invoked while all the runspaces in this worker process are busy handling other invocations), so the next concurrent invocation will have to wait for a runspace initialization again. For Premium and App Service plan users, this will be even more surprising and confusing than #453, since the worker instance is already executing functions, so it is expected to be warm enough.

Proposal

Start pre-creating up to PSWorkerInProcConcurrencyUpperBound runspaces on the first function load request, anticipating but not waiting for function invocations. Create these runspaces on background threads, without blocking the function load request. As a result, the worker may consume (and potentially waste) more resources, but function start time will improve.

This is a tradeoff that may visibly affect some users, so consider making this behavior configurable, with the new behavior as a default.

As the first step, pre-create exactly PSWorkerInProcConcurrencyUpperBound runspaces for now. Later, consider implementing a more sophisticated strategy if still necessary (e.g. pre-create just half of this number, adjust it dynamically, etc.) Chances are, the simplest implementation will be good enough.

[draggeta]

I have to say that I would like this too. Having the runspaces ready to go would improve performance so much at the cost of a longer one-time initial startup.