Android / iOS / tvOS specific HttpClientHandler

[EgorBo]

Implements #46646 and #47083 (comment)

Per https://github.com/dotnet/designs/blob/main/accepted/2020/mono-convergence/platform-specific-httpclient.md , the default HttpClientHandler will be the native handler specific to Android, iOS, and tvOS.

To fall back to SocketsHttpHandler, simply set the System.Net.Http.UseNativeHttpHandler AppContext switch.

AppContext.SetSwitch("System.Net.Http.UseNativeHttpHandler", true);

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Implements #46646

Should make .NET6 compatible with what XA currently have:

1. "ComboBox" with custom http handlers in VS and VSfM
   
2. <AndroidHttpClientHandlerType>AndroidClientHandler</AndroidHttpClientHandlerType> property in csproj
3. Special ILLink sub-step (PreserveHttpAndroidClientHandler) to remove/preserve the native android handler if it's not used.

Author:	EgorBo
Assignees:	-
Labels:	area-System.Net.Http
Milestone:	-

[stephentoub]

will use the default SocketHttpHandler even if the native one was selected in VS

Did we decide that's not a scenario we care about?

[EgorBo]

will use the default SocketHttpHandler even if the native one was selected in VS

Did we decide that's not a scenario we care about?

It's open for discussion, I was just repeating the current XA behavior.

[steveisok]

will use the default SocketHttpHandler even if the native one was selected in VS

Did we decide that's not a scenario we care about?

I don't see a reason not to preserve the existing behavior. But as Egor said, definitely up for discussion.

[steveisok]

@EgorBo @akoeplinger Thoughts on how we can test this?

[stephentoub]

I don't see a reason not to preserve the existing behavior

If the existing Xamarin behavior is that new HttpClientHandler() doesn't respect the user choice and may not work correctly, and we haven't heard much concern, ok.

[EgorBo]

@EgorBo @akoeplinger Thoughts on how we can test this?

Either leave it for XA repo or implement that Android Handler via JNI (we can't just re-write it to JNI and use it even for XA because it already exposes some XA APIs in public (to override if users want) so we'll have to maintain two implementation in this case 😐

[eerhardt]

@EgorBo @marek-safar - What is the plan to address this warning? We had this library ILLink "clean" already, and so it was no longer being tracked by #45623.

In the future, we should not be adding new ILLink warning suppression xmls to the libraries that are already clean. We need to address the ILLink warnings on any new features we add as we go.

[marek-safar]

The suppression is intentional and will stay there. We could ideally move it to Library.xml but I think we tried that and it had some problems.

Edit: just realized you were taking about XML file. Yes we should move the suppression to the code.