Send command line args with non-generic names to language worker

[kshyju]

The command line arguments we currently send to language worker process has generic names (HOST, PORT etc). This would cause conflict with other environment variables in certain environments. For example, dotnet isolated in Linux + VNET is one of those cases where the PORT gets overwritten when the customer calls "ConfigureAppConfiguration" in the main method (as shown in Azure/azure-functions-dotnet-worker#1547)

We want to send these args with FUNCTIONS_ prefix. Initially we will send both (ex: HOST and FUNCTIONS_HOST) and once all language workers adopts to the new arguments & we are confident that no existing apps are using the old approach, we shall consider retiring the old ones.

Language workers are advised to use the new command line arguments if present, and fallback to existing one.

We also decided to combine the host and port part to a single argument "functions-uri".

For example, for dotnet-isolated worker, we will do something like below

grpcWorkerStartupOption.RequestId= config["functions-requestid"] ?? config["requestid"];

where config is an instance of IConfiguration which contains all command line arguments. We will first check FUNCTIONS_HOST entry is present and use it's value if present, else will use host.

Issues tracking fixes on language workers side to support the new arguments (to not throw while parsing)

• Update language worker to support parsing command-line arguments prefix with functions-<argumentname> azure-functions-powershell-worker#992
• Update dotnet worker to handle the additional command line args with "functions-" prefix azure-functions-dotnet-worker#1900
• Update java language worker to support handling new command line arguments with functions- prefix azure-functions-java-worker#724
• Update python language worker to support handling new command line arguments with functions- prefix azure-functions-python-worker#1314

[jviau]

1. Can we combine this into FUNCTIONS_URL?
2. For command line, can we make sure to use --functions-url and make sure it maps to FUNCTIONS_URL in IConfiguration? (I think this may be the default behavior, but would need to verify).