Terminate process tree on ctrl+c

[SteveL-MSFT]

PR Summary

• move test_group_resource under tools where all test specific code should go
• created dsctest exe to be used with Test/Sleep resource for manually validating ctrl+c. Future test resources should be subcommands of this exe.
• fn to discover process tree under the current dsc process and terminate each one
• fix build.ps1 to correctly replace debug and release paths on non-Windows
• add InputKind = Arg to allow passing the input JSON as an argument. See Test/Sleep resource on example usage.
• added a few info traces to help see what was happening during validation

PR Context

Terminate subprocesses upon ctrl+c

[michaeltlombardi]

I'm not sure about this change/implementation from the user-facing perspective and the schema - it moves the schema from a set of enum values (in JSON Schema syntax) to a oneOf that is more complicated and harder for users to adjust/grok.

I would propose an enum value like ReplaceArg (replaceArg in the JSON) that always replaces a static string argument in the list, instead of allowing an arbitrary string.

We could have that argument be something like {{instance_json}} to be very unlikely to conflict with any actual arguments.

Then the manifest would look like:

"set": {
  "executable": "foo",
  "args": ["config", "set", "--input", "{{instance_json}}"],
  "input": "replaceArg"
}

From a schema perspective, we can then validate that when input is replaceArg that args includes the static string and not when input is any other value.

Are there cases where users will need to specify a custom value for the replacement string?

allOf:
  - if: { properties: { input: { const: replaceArg } } }
    then:
      properties:
        args:
          contains:  { const: '{{instance_json}}' }
          minContains: 1
          maxContains: 1
    else:
      properties:
        args:
          not: { contains:  { const: '{{instance_json}}' } }

[SteveL-MSFT]

@michaeltlombardi please open a new issue to discuss

[miroman9364]

Code-wise, this looks good to me. If the arg processing needs to change, it can be done in an update.