Small optimizations in System.Net.NetworkInformation

[teo-tsirpanis]

This PR does two small optimizations:

• In the TeredoHelper class, we used to queue a callback to the thread pool by using the good old ThreadPool.QueueUserWorkItem method. I changed it by implementing the IThreadPoolWorkItem interface in TeredoHelper, and queueing it directly to the thread pool, saving an allocation, and avoiding needlessly flowing the ExecutionContext (judging from the name TeredoHelper.UnsafeNotifyStableUnicastIpAddressTable).
• The SystemIPGlobalProperties.GetUnicastAddressesAsync was creating a TaskCompletionSource<bool>, while the newer non-generic TaskCompletionSource class is more appropriate and has a tiny bit smaller footprint. I changed it.

[ghost]

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

Issue Details

---

This PR does two small optimizations:

• In the TeredoHelper class, we used to queue a callback to the thread pool by using the good old ThreadPool.QueueUserWorkItem method. I changed it by implementing the IThreadPoolWorkItem interface in TeredoHelper, and queueing it directly to the thread pool, saving an allocation, and avoiding needlessly flowing the ExecutionContext (judging from the name TeredoHelper.UnsafeNotifyStableUnicastIpAddressTable).
• The SystemIPGlobalProperties.GetUnicastAddressesAsync was creating a TaskCompletionSource<bool>, while the newer non-generic TaskCompletionSource class is more appropriate and has a tiny bit smaller footprint. I changed it.

Author:	teo-tsirpanis
Assignees:	-
Labels:	area-System.Net, community-contribution
Milestone:	-

[stephentoub]

Thanks. It's fine to change the TaskCompletionSource<T> to a TaskCompletionSource, but we should stick with QueueUserWorkItem. Saving one tiny allocation here for something that's probably only invoked once in the lifetime of the app isn't worth the complication of having yet another IThreadPoolWorkItem implementation, complicating debugging (e.g. the work item won't be inspectable by VS' implicit understanding of "normal" work items), etc.

[teo-tsirpanis]

Done @stephentoub. Can you tell me more about this debugger limitation with IThreadPoolWorkItemss? I'm interested to learn.

[stephentoub]

Debuggers know about the built-in work item types. They know about their layout, what their fields mean, etc. An arbitrary IThreadPoolWorkItem is an unknown entity. They can't reason about what it is, what it represents, etc.