Add capabilities update strategy to environment reload response

[satvu]

Even though updated capabilities are sent in an environment reload response, they are not always applied correctly (Related host PR: Azure/azure-functions-host#9367). Furthermore, there may be cases where we need different strategies for applying capabilities. Some examples from @brettsam:

1. In placeholder mode, worker tell us capability A, B, C. when specialized, it sends us nothing (python example). We should just leave A, B, C -- otherwise we would break the worker.
2. In placeholder mode, worker tell us capability A, B, C. When specialized, it sends us A, B, D. Today we'd make this A, B, C, D -- but should it be A, B, D?

This PR adds a property to the environment reload response message indicating to the host which strategy to use when receiving updated capabilities from a worker.

[ejizba]

Cool! Just fyi, if/when the Node.js worker uses this we will probably use 'replace' just so that we can handle any merging ourselves

[Francisco-Gamino]

Cool! Just fyi, if/when the Node.js worker uses this we will probably use 'replace' just so that we can handle any merging ourselves

We will probably do the same for the PowerShell language worker.

[Francisco-Gamino]

LGTM

[AnatoliB]

@satvu @brettsam Based on the known cases, do you know if removing capabilities on the worker side after specialization is intentional, and not just a bug on the worker side? I can imagine such cases in theory, but I'm wondering if we have a legitimate use case for that. Otherwise, perhaps 'replace' is all we ever need?

[satvu]

@satvu @brettsam Based on the known cases, do you know if removing capabilities on the worker side after specialization is intentional, and not just a bug on the worker side? I can imagine such cases in theory, but I'm wondering if we have a legitimate use case for that. Otherwise, perhaps 'replace' is all we ever need?

@AnatoliB I don't believe we have a use case for removing capabilities, but to answer your last question, "merge" is an option and our current choice for default since it best describes the host's behavior today. We do currently update capability values - it's the re-application/parsing of capabilities following an environment reload that is the bug. Moving to just "replace" will require more validation as it is different from the current behavior, and we do not want to accidentally break anyone by completely switching to a new strategy (scenario 1 in description).

Given the popularity of "replace" though, the "merge" option may end up being unused in the future.

[brettsam]

Yeah, "merge" may be unsupported at some point. I'd assume most workers would want to figure it all out on their own and just send a completely new list with "replace".

But we saw the python worker today sends us an empty payload on Environment Reload. So instead of special-casing this, we decided to make "merge" a first-class option and make it the default.