Deployment profile behavior on Windows

[gunamata]

The way Windows deployment profile seems to be a bit different from what's intended.

Of the below 2 registry settings, the definition in RD_Phil.txt produces the desired behavior in the app but still requires changes to support broad cases such as WSL Integration etc.. @jandubois , Can you please expand what we discussed and take it from here?

RD_Guna.txt
RD_Phil.txt

[jandubois]

The implementation doesn't follow the spec from #3750:

Except for maps, all values use the "default value" (lpValueName being the empty string). Maps store the various values under their respective key names.

The current implementation doesn't expect a separate key for each setting, but puts them as a named value under the key one level up.

This will not work for diagnostics.mutedChecks and WSL.integrations because their values are maps with multiple keys, and there is not REG_* data type for multi-value objects (with the exception of REG_MULTI_SZ for a list of strings).

[jandubois]

Based on the fact that regedit.exe doesn't seem to allow changing the type of the default entry, maybe the current implementation has advantages in usability. So maybe we should adjust the spec instead? Will need to think about it a bit more.

[jandubois]

So maybe we should adjust the spec instead?

We decided that the current implementation will override the original spec because it has better usability.

[ericpromislow]

There's still more to do:

1. Verify types of values in the registry conform with types in the schema
2. Process WSL/integrations, diagnostics/mutedChecks, and extensions as string=>boolean hashes
3. Complain about unrecognized fields found in the registry, but don't complain about fields in the schema that aren't present in the registry

[ericpromislow]

There's a better issue on this - #4153