Improve the registry reader

[ericpromislow]

A list of TODO items (from code review on #4148)

[x] Separate walking the subkeys from walking the values
[x ] Remove the comment 'Alternatively, if the keys work, we could break, even if both hives are empty....'
[x ] Give readRegistryUsingSchema a consistent return type

• Can't do much better than RecursivePartial<settings.Settings>|null
  [x] Report unrecognized registry keys and values
  [x] Clarify array processing, like do that before walking sub-objects
• That's being done now when reading MULTI_SZ values
  [x] See if I can remove the cast multiSzValue as nativeReg.Value
• This is done by using nativeReg.queryValueRaw to get a (type, value) pair of the registry value, and then casing on the type field to parse out the correct kind of value.
  [x] line 167: Is regValue ever not an object? - This code has changed too much to point to what this comment was referring to, or determine if it's still valid.
  [x] Pass in the current registry path so we can report the full path in error-messages, not just the current key
  [x] More type-checking is needed when reading in registry values, e.g. when reading a string into a number, etc.

[jandubois]

• Report unrecognized registry keys and values

This should not be done (see #4148 (comment))!

We should only fail on incorrect types. In which case RD should refuse to start.

[mook-as]

There's also the corner case of if the user supplies a DWORD to a thing that expects a string[], how do we cast it (if we do at all; we also have the option of not accepting it).

[jandubois]

the user supplies a DWORD to a thing that expects a string[]

This should be a fatal error. I think supplying a DWORD for just a plain string should be an error too.

I expect the same things to be an error in the other formats too, e.g.

{ "experimental": 42 }

should fail because experimental must be an object and not a number.

We also need to make sure the settings pass the validator; if they don't, we should also refuse to start.

[IsaSih]

Tested on windows 11 providing settings with incorrect registry types. Rancher Desktop is just ignoring the deployment profiles and showing the first-run dialog. It is NOT throwing a fatal error.

Reg file used:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Rancher Desktop\Profile]
[HKEY_CURRENT_USER\Software\Rancher Desktop\Profile\Defaults]
[HKEY_CURRENT_USER\Software\Rancher Desktop\Profile\Defaults\kubernetes]
"enabled"=dword:00000001
[HKEY_CURRENT_USER\Software\Rancher Desktop\Profile\Locked]
[HKEY_CURRENT_USER\Software\Rancher Desktop\Profile\Locked\containerEngine]
[HKEY_CURRENT_USER\Software\Rancher Desktop\Profile\Locked\containerEngine\allowedImages]
"disabled"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Rancher Desktop\Profile]
[HKEY_LOCAL_MACHINE\Software\Rancher Desktop\Profile\Defaults]
[HKEY_LOCAL_MACHINE\Software\Rancher Desktop\Profile\Defaults\containerEngine]
"name"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Rancher Desktop\Profile\Defaults\kubernetes]
"enabled"=42
[HKEY_LOCAL_MACHINE\Software\Rancher Desktop\Profile\Locked]
[HKEY_LOCAL_MACHINE\Software\Rancher Desktop\Profile\Locked\containerEngine]
[HKEY_LOCAL_MACHINE\Software\Rancher Desktop\Profile\Locked\containerEngine\allowedImages]
"enabled"=dword:00000001
"patterns"=hex(7):62,00,75,00,73,00,79,00,62,00,6f,00,78,00,00,00,6e,00,67,00,\
  69,00,6e,00,78,00,00,00,00,00

Note that the values with incorrect reg types are:

[HKEY_LOCAL_MACHINE\Software\Rancher Desktop\Profile\Defaults\containerEngine]
"name"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Rancher Desktop\Profile\Defaults\kubernetes]
"enabled"=42

[IsaSih]

Tried again and this time application failed to start. Moving issue to done.