Initial implementation of legacy soap config management

[ritchiecarroll]

This handles processing of legacy XML serializations of configuration frames, loading and saving, to allow for operational cached config file implementations. This allows compatibility with the PMU Connection Tester and faster time to data for UDP connections at startup using last known good config.

Related PRs:

• Improved legacy serialization binder common#27
• https://github.com/snapdb/openHistorian/pull/156

[StephenCWills]

I'm hesitant to approve this without at least having a discussion about whether we can break away from using this legacy SOAP format.

https://learn.microsoft.com/en-us/dotnet/api/system.runtime.serialization.formatters.soap.soapformatter?view=netframework-4.8.1#remarks

[ritchiecarroll]

I'm hesitant to approve this without at least having a discussion about whether we can break away from using this legacy SOAP format.

https://learn.microsoft.com/en-us/dotnet/api/system.runtime.serialization.formatters.soap.soapformatter?view=netframework-4.8.1#remarks

Yeah, that security issue referenced was top of mind during development, this does not use BinaryFormatter or SoapFormatter. It also rips out the third-party NuGet port that was being used before -- so, retiring the flagged issue, not doubling down on it.

What's left is a purpose-built reader for our singular config-frame schema -- not a general graph deserializer. Here so the reasons it's not in the BinaryFormatter danger zone:

1. Key safety item: PR code can't load arbitrary types. Default binder (internal SafeBinder) only resolves types from Gemstone.PhasorProtocols / Gemstone.Numeric and fails closed on anything else — before a single object is allocated. That's literally the mitigation MS recommends, in the strict form. Every known dangerous gadget type lives in System.*/third-party, so they can't even be named.

2. PR code never fires the instantiated class triggers. No OnDeserialization, no IObjectReference, etc. — just the plain (SerializationInfo, StreamingContext) constructors. The attack chains all activate through paths that don't get called.

3. PR code uses local cache files, read on startup, with XXE/DTD turned off. There's a unit test LegacySoapSecurityTests.cs for proving the allowed list operations.

On your real question -- can we ditch the SOAP format? For "reading it", would prefer to "keep that" (even if primary I/O format is changed to another format). Key thing being cached PMU Connection Tester configs that can be used during device setup. Could change connection tester too, but I have hundreds of these old .configuration.xml files which I find handy, end user's will have them, they are "in the field" and usable -- so I like the idea of a "reader".

Writing it, yes, could switch to JSON or something. Currently the output is interoperable with PMU Connection Tester, but the writer code is cleanly separable, so a JSON (or other) write path is an easy follow-up (with associated reader) whenever we want -- but the writing part is not where any dragons lie.