Add config + implementation for stand-by instantly-available "runners" (for hot code paths)

[alvin]

What would you like to be added:

• Docker and/or other runtime substrates and/or the system itself could be configured to have N "runner" instances on standby, ready to respond to events or requests

Why is this needed:

• Some "hot path" code scenarios will benefit greatly from instant execution of workflow functions vs. waiting for a runtime environment to spin up.

Things to consider:

• Process security/isolation + concurrency factors
• Should it be limited to functions / calculations without external side-effects? Something like a dedicated pool of runners to handle all python or all javascript "call" requests?
• Or consider a set of input context constraints that result in an isolated "pool" of runners that do have external connections -- what comes to mind for me here is a runner instance (or group/set) that has an open database read/write connection to an external database -- for isolation purposes we might want to route to that runner/set only when the requesting tenant context matches that of the runner/set
• Where to configure this functionality?
• Where to code/enable this functionality?: In the operator? The correlator? (Or even isolated to the runtime layers -- eg. maybe K8S/helm supports it but docker doesn't)

@cdavernas is this an accurate feature request based on our discussion?

[cdavernas]

@alvin yes, sounds perfect! Thank you!!!

[bvandewe]

This would be lovely! +1