Rework Linux/Kerberos native interop layer

[davidsh]

The latest changes to the System.Net.Security.Native shim layer fixed a lot of important
bugs for Linux Kerberos usage. But this created a new problem since SqlClient ships
in out-of-band NuGet packages separate from the .NET Core runtime. SqlClient builds
out of the CoreFx repo and uses the common source includes for Kerberos authentication.
This created an unexpected dependency on the System.Net.Security.Native shim layer.
The recent changes to these API signatures caused problems with different combinations
of SqlClient NuGet packages and .NET Core 2.x versus .NET Core 3.0.

After discussion with the SqlClient team, we decided to rework the changes to these
native APIs so that they would remain compatible across all .NET Core versions.

Long-term, the plan is to implement #36896 to expose a Kerberos API in .NET Core which
could be used by SqlClient and other consumers.

Closes #37183
Closes #25205

[davidsh]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[jkotas]

How are we going to test that all possible combinations actually work?

I am wondering whether it would it be better to keep the verbatim 2.1 implementation of the shim APIs, without any changes and big comment at the top of the file that this is for SqlClient compat only and can be deleted once this compat hack does not need to be maintained anymore. And then have the live version of the shim APIs that SqlClient would not have dependency on anymore and that we can evolved without worrying about compatibility with SqlClient.

[davidsh]

How are we going to test that all possible combinations actually work?

I've been manually testing the combinations to make sure things work ok.

I am wondering whether it would it be better to keep the verbatim 2.1 implementation of the shim APIs,

The original .NET Core 2.1 implementation of System.Net.Security.Native has bugs that we had to fix in .NET Core 3.0 master such as Negotiate Kerberos to NTLM fallback and channel binding token (CBT).
We plan to port some of these functional fixes in master to the release/2.1 branch in order to unblock some customers that are depending on the .NET Core 2.1 release (which is LTS). But these fixes and this .NET Core 3.0 master branch PR creates a compatible layer since we will keep the API signatures the same as .NET Core 2.1 for the APIs that SqlClient is using from this layer.

[wfurt]

should we use '@' here to avoid need to copy & replace later?

[davidsh]

The "@" format is only for Linux. The Windows format always use "/". The current code (before this PR) has different files for Windows vs. Linux. This PR undoes that to go back to what it was before I made those change a month ago.

The problem is that this managed code here in CoreFx for SqlClient builds as separate package. And that package can run against an older .NET Core 2.1 runtime. And that runtime which uses System.Net.Security.Native doesn't understand the "@" format. So, right now the latest pre-release packages of System.Data.SqlClient (based on this master branch, .NET Core 3.0) is broken. So, this PR is trying to keep the managed layer the same as what it was in .NET Core 2.1.

This is why the logic for transformation of "/" to "@" moves to the C layer which doesn't build as a separate (out-of-band) package.

[wfurt]

LGTM.