Add support for TcpIP in all tooling using ReverseDiagnosticsServer.

[lateralusX]

PR #2050 add TcpIP support into ReverseDiagnosticsServer. Part of that PR only enables it for the dsrouter components and prevent other tools to use it by adding a specific constructor to ReverseDiagnosticsServer that needs to be used in order to enable TcpIP support. It was done this way to limit the ability to start TcpIP listeners as part of existing tooling using ReverseDiagnosticsServer (dotnet-counters, dotnet-trace).

By removing this limitation we could open up the possibility to run ReverseDiagnosticsServer using TcpIP listener instead of NamedPipes/UnixDomainSockets, in all tools currently working with the reverse connect scenarios for runtime supporting diagnostics server TcpIP transports . This would enable users to use the --diagnostic-ports argument with a TcpIP endpoint, like tcp://127.0.0.1:x and if detected as a valid TcpIP address ReverseDiagnosticsServer will use TcpIp transport instead of NamedPipes or UnixDomainSockets.

/CC @josalem @shirhatti

[josalem]

It is worth noting that this functionality is not for general use and is explicitly for use in debug builds of the Mono runtime with iOS/Android. The functionality to use this from the runtime side is not compiled in to CoreCLR or any release builds.

[lateralusX]

Correct, you will need a special build of the runtime to enable TcpIP support (initially only part of iOS/Android devloop configurations) as well as setting the DOTNET_DiagnosticPorts environement variable before launching the runtime in order to connect to the ReversedDiagnosticsServer using TcpIP. Also note that the ReversedDiagnosticsServer needs to be configured using a TcpIP interface when launched in order to accept connections. It is also highly recommended to only bind loopback interface when using this scenario (both iOS/Android can connect over loopback using simulator or device connected over usb).

[lateralusX]

An alternative solution is not injecting TCP/IP support into diagnostic tooling, but to enable ipc server<->ipc server in dsrouter, that way we could push the reverse diagnostic server solution into dsrouter and have all clients act as regular IPC clients. Injecting regular TCP/IP support into diagnostic clients will probably not happen, TCP/IP endpoints are taken care of by dotnet-dsrouter.