Add IsDisabled property to worker description and skip if the value is True

[kshyju]

Fixes #9932

Adding IsDisabled property to worker description. This allows language workers to enable/disable a worker based on profile conditions. This is an optional property. If not provided, the worker will not be skipped.

Here is a sample worker config which takes advantage of this property.

{
  "description": {
    "language": "bar"
  },
  "profiles": [
    {
      "profileName": "SpecificConditionProfile",
      "conditions": [
        {
          "conditionType": "environment",
          "conditionName": "NON_EXISTING_ENV_VAR",
          "conditionExpression": "(?i)true$"
        }
      ],
      "description": {
        "defaultExecutablePath": "%FUNCTIONS_WORKER_DIRECTORY%/2.bat",
        "defaultWorkerPath": "2.bat"
      }
    },
    {
      "profileName": "FallbackProfileToDisableWorker",
      "conditions": [
        {
          "conditionType": "environment",
          "conditionName": "EXISTING_ENV_VAR",
          "conditionExpression": "(?i)true$"
        }
      ],
      "description": {
        "defaultExecutablePath": "%FUNCTIONS_WORKER_DIRECTORY%/2.bat",
        "defaultWorkerPath": "2.bat",
        "isDisabled": true
      }
    }
  ]
}

Pull request checklist

IMPORTANT: Currently, changes must be backported to the in-proc branch to be included in Core Tools and non-Flex deployments.

• Backporting to the in-proc branch is not required
  • Will follow backport PR. [InProc] Add IsDisabled property to worker description and skip if the value is True #10250
• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr - [InProc] Add IsDisabled property to worker description and skip if the value is True #10250
• My changes do not require diagnostic events changes
  • Otherwise: I have added/updated all related diagnostic events and their documentation (Documentation issue linked to PR)
• I have added all required tests (Unit tests, E2E tests)

Additional information

Additional PR information

[fabiocav]

Submitting some minor comments, but also had a design sync with @kshyju

[kshyju]

Submitting some minor comments, but also had a design sync with @kshyju

After syncing with fabio, I pushed an iteration where I changed the property to a more generic IsDisabled property which profiles can override. If the property value is True, that profile will be skipped.

[fabiocav]

Minor nit comment, but the change looks good!