Networking: Remove APM code samples, add Task-based code samples

[antonfirsov]

We agreed in a @dotnet/ncl team discussion that fixing existing APM code samples is not worth the efforts. We should instead scrap them, and introduce code samples for Task-based API-s.

Affected classes:

• Socket
• NetworkStream
• TCPClient
• TCPListener
• SslStream

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

Issue Details

---

We agreed in a @dotnet/ncl team discussion that fixing existing APM code samples is not worth the efforts. We should instead scrap them, and introduce code samples for Task-based API-s.

Affected classes:

• Socket
• NetworkStream
• TCPClient
• TCPListener
• SslStream

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[antonfirsov]

Ok, I have given this another thought, and now I believe that the API doc samples section is really not the right place to present meaningful examples.

• Either we create long (and opinionated) samples which take a lot of space, listing the same (or slightly modified version of the same) example across multiple pages.
• Or we may end up creating meaningless minimalistic questionable code snippets.

We don't have such embedded examples for HttpClient and I don't see any issues that suggest adding them, which is probably good.

For comparison, let's look at a particular place in the BCL docs with embedded examples on a similar API:
https://learn.microsoft.com/en-us/dotnet/api/system.io.filestream.readasync?view=net-7.0
Just a few issues I noticed:

• The same sample is used to demonstrate two overloads, however only one is used.
• It ignores the return value of ReadAsync().
• It presents a questionable pattern to do asynchronous IO + UI update for a WPF example

Getting this right is not easy, therefore I think bothering to create proper embedded Socket examples is not the right investment. I would rather spend the time on the improvement of the Socket conceptual docs (docs/#31702 and ideas from #7714 and #7609 (comment)), and just link them from the API docs. If a user is actually interested understanding the API, they will follow the link.

/cc @ManickaP @wfurt @liveans