Description: This is part 2 of 2 for merging SNI native method wrappers. It's a little more involved than before and requires a bit of explanation.

In the netfx version of the SNI native wrapper, the SniNativeWrapper class is truly a wrapper around three native libraries (x86, x64, and arm64). The prior code for this had a switch on each case that would check the architecture of the system and call the appropriate native library. This isn't ideal since it requires a switch statement each time a native SNI call is made. A better approach would be to have the wrapper call into a native library that is picked at static construction of the wrapper.

However, there are limitations to this approach:

1. The only difference between the three native libraries is the name of the[DllImport] dll. However, this must be a compile time constant. This means there must be a class for each of the native libraries.
2. In order to use[DllImport], the method must beextern, which must bestatic. Interfaces cannot have static methods (at least not prior to net7, iirc), so in order for the library classes to implement an interface, they have to have an instance method that calls into the static, extern method.
3. The easiest way to integrate the netcore implementation into this pattern is to have a implementation of the interface that uses the netcore dll. This introduces a bit of unnecessary indirection, but I think it will be negligible.

Thus, here is the class hierarchy:

• SNINativeMethodWrapper [netfx],SNINativeMethodWrapper.Windows [netcore]
  • ISniNativeWrapper [netfx, netcore]
    • SniNativeMethods [netcore]
    • SniNativeMethodsArm64 [netfx]
    • SniNativeMethodsNotSupported [netfx] - used when architecture is not supported
    • SniNativeMethodsX64 [netfx]
    • SniNativeMethodsX86 [netfx]

Although I can't speak in specifics, when comparing the performance of a switch per call and calling an interface which calls the method, the interface approach is significantly more performant. (sorry@David-Engel )

Testing: For the most part, this just moves code around and doesn't really change the functionality. Everythingshould still work, but the native SNI CI tests will confirm.