Fix eager native SNI initialization on non-Windows platforms

[shreyarao4]

Description

After #4465, the same SqlClient code is built for both Windows and non-Windows platforms, with native or managed SNI selected at runtime.

SNILoadHandle contains a static singleton:
internal static readonly SNILoadHandle SingletonInstance = new SNILoadHandle();
Because SNILoadHandle has no explicit static constructor, its treated as beforefieldinit. This allows the runtime to initialize the type before SingletonInstance is actually accessed.

The SNILoadHandle constructor calls the Windows-only native SNI initialization:
SniNativeWrapper.SniInitialize();

On non-Windows platforms, managed SNI is selected and SNILoadHandle should not be initialized. However, because of beforefieldinit, the runtime can initialize SNILoadHandle merely because it is referenced by JIT-compiled code.
This causes the Windows-only native SNI library to be loaded on non-Windows platforms and results in the following DllNotFoundException.

System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.SNILoadHandle' threw an exception.
 ---> System.DllNotFoundException: Microsoft.Data.SqlClient.SNI.dll
   at Interop.Windows.Sni.SniNativeMethods.SniInitialize(IntPtr pmo)
   at Microsoft.Data.SqlClient.SniNativeWrapper.SniInitialize()
   at Microsoft.Data.SqlClient.SNILoadHandle..ctor()
   at Microsoft.Data.SqlClient.SNILoadHandle..cctor()
 --- End of inner exception stack trace ---
   at System.Runtime.InteropServices.SafeHandle.InternalRelease(Boolean disposeOrFinalizeOperation)
   at System.Runtime.InteropServices.SafeHandle.Dispose(Boolean disposing)
   at System.Runtime.InteropServices.SafeHandle.Finalize()
   at System.GC.GuardedFinalize(Object o)

Solution

Added an explicit static constructor to SNILoadHandle.
This removes the beforefieldinit behavior and ensures that static initialization happens only when SNILoadHandle is actually accessed.
Therefore, on Linux, SNILoadHandle is not initialized when the managed SNI path is selected, and the Windows-only native SNI library is never loaded.

Testing

Verified on Linux/s390x: ManualTests previously crashed with the DllNotFoundException above; after this change, tests run sucessfully.

Environment

Linux s390x
Mono runtime

@giritrivedi

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[edwardneal]

That load behaviour is very eager - the code paths are unreachable as a result of OsConstants.IsWindows returning false, I'm surprised that the JIT is even able to see the native SNI to try and initialize it. Tests have been continuing to pass on Linux and macOS using the updated package for the last two months, has this been seen on platforms besides s390x?

[shreyarao4]

I have not verified on any other platforms, but please note this is using Mono runtime. dotnet/runtime#77513 confirms this behavior on Mono. Mono eagerly runs a beforefieldinit type's static constructor even when the accessing code path is never taken.