Option to not use WebRequest for PictureBox

[kant2002]

Indirectly related to #1756 because if that would work, I would be able to fix #1756 using the same approach.
WebRequest bring ton of code to WinForms which is old, and not really interesting. NativeAOT suffer from this.

Inspired by dotnet/runtime#38397

By itself if applying <RuntimeHostConfigurationOption Include="System.Windows.Forms.PictureBox.UseWebRequest" Value="false" Trim="true" /> it will shave 1Mb from 20Mb of my sample application which compiled under NativeAOT. I include all controls in that application.

Microsoft Reviewers: Open in CodeFlow

[kant2002]

If subsequently apply kant2002@7ce82f2 then application trimmed to 15Mb and that with reflection

[kant2002]

@RussKie do you think, this PR require some additional work?

[RussKie]

Apologies for the delay, I’m working on multiple streams and stretched pretty thin atm. I’ll try to get to this asapp.

[JeremyKuhne]

I'd stick with putting this in the existing Task.Run and avoid introducing async.

[kant2002]

@JeremyKuhne did I infer your proposal correctly?

[JeremyKuhne]

Spending some more time looking at this I think you'd be better off using the existing ReadCallBack(). Let me know if that doesn't work for you or if you have any other questions.

[JeremyKuhne]

@kant2002 appreciate your effort here.

[kant2002]

@JeremyKuhne reason why I did use async/await in "new" implementation is because I think they are easier to reason about. And seems here appetite eventually move to HttpClient so async/await is would be natural choice. Since this is new code path, "some regressions" maybe acceptable for target audience.

Anyway, I update as you suggest the code. I do not have questions and this approach is fine.

[JeremyKuhne]

I think they are easier to reason about.

Normally, I'd agree. As this code predates async you introduce a fair amount of cognitive overhead if you mix and match approaches. While the code could be completely rewritten to leverage new patterns I'd hesitate to do so without a strong justification.

Since this is new code path, "some regressions" maybe acceptable for target audience.

I think the default position should be "no differences in functionality". We can, of course, alter that based on data and discussion.

Again, thanks for your effort here.

[JeremyKuhne]

Looks good!