Bump schema and embedded socket client

[marcus-j-davies]

@spudwebb

Do you want to pull this code?

• Adds Support for Long Range (there are extra keys in the settings class to support this)
  Testing this may be difficult (impossible) as devices are still being surfaced.
  The controller now has a property called supportsLongRange + the ZWaveNode class now has a property called protocol

• Adds a Utils class to the Driver
  This provides access to ParseQRCodeString as The ZWA insist in users being provided a choice, as to use ZWave LR or classic (and the result in the CMD payload is QRProvisioningInformation)
  This can then be modified before passing to ProvisionSmartStartNode (and importantly, allowing users to switch to LR if supported/detected in the QR Code)

• ProvisionSmartStartNode now has an overload to provide a QRProvisioningInformation instance (to aid the above)

• Bump Scheme to 35

• Embeds the Socket Lib (4.7.0)- right before it got bumped to v5 (removing NS2.0)
  and this contains the stack overflow fix

  Have tested the lib, and all seems to be fine.

[spudwebb]

@marcus-j-davies I will test tomorrow.

I build it though, and there is now a lot of compilation warnings caused by the fact that the nullable context is now enabled for the whole project. I think it is a bit dangerous to enable it for the whole project because now all reference type variables in the ZWaveJS.NET code are considered non nullable whereas they were previously nullable.

So instead, I would keep the nullable setting as disabled at the project level, and I would add preprocessor directives at the beginning of each file of the Websocket.Client code
#nullable enable

https://learn.microsoft.com/en-us/dotnet/csharp/nullable-references#nullable-contexts

Thanks for the long range support, we plan to add that soon too.

[marcus-j-davies]

Thanks @spudwebb

Have removed the global setting, and switched them were needed
There are 2 warnings referring to 2 libs not tested in .NET5.0, so I will need to test that tomorrow, it may be fine.

• System.Threading.Channels
• Microsoft.Extensions.Logging.Abstractions

[marcus-j-davies]

@spudwebb
The fallouts from embedding the socket code should now be addressed

The new targets are : net48 net6.0 net7.0 net8.0 netstandard2.0 netstandard2.1
net5.0 was causing a lot of the issues, and it seems this should not be included as a target these days

No modification on Socket source code (the last commit before v5) was needed (tested with a .NET 4.8 console app)
and of course contais the SOF crash fix

I have included a test console app, to demo LR - LR can only be achieved with Smart Start.
I have included just as a reference, not as an expectation to utilise it yet 😄

ZWaveJS.NET.ZWaveOptions ZWO = new ZWaveJS.NET.ZWaveOptions();

ZWO.securityKeys.S0_Legacy = "c84de525ba1382374615f93427a18138";
ZWO.securityKeys.S2_AccessControl = "3d18628e80743ebaf96d97707cffb139";
ZWO.securityKeys.S2_Authenticated = "c2da28bc56ad5484fcf10efd2a1ed1c1";
ZWO.securityKeys.S2_Unauthenticated = "69ded77863e0b64401f1ac12c4d15c86";

ZWO.securityKeysLongRange.S2_AccessControl = "1e76388da0674c6d799e6f1f6bef0c91";
ZWO.securityKeysLongRange.S2_Authenticated = "6b948cf3ea8679e57b7f89cce47bcb18";

ZWO.logConfig.logToFile = false;
ZWO.logConfig.enabled = true;
ZWO.enableSoftReset = false;

ZWaveJS.NET.Driver D = new ZWaveJS.NET.Driver("COM3", ZWO);

D.DriverReady += () => {

    D.Utils.ParseQRCodeString("900143047006000000000000000000000000000000000000000000100025800002022000004000050000601800080201").ContinueWith((R1) =>
    {
        QRProvisioningInformation QRI = R1.Result.ResultPayload as QRProvisioningInformation;

        // Modify based on users choice (Protoccol)
        // Then...
        // D.Controller.ProvisionSmartStartNode(QRI).ContinueWith((R2) => { ... });
    });
            
};

D.Start();
Console.ReadLine();

Let me know if this PR (more so the recent commit to it -> 23c58fb) is working for you

[spudwebb]

Everything is working as expected. Thanks a lot!