Support Controlling EventPipe by using a named pipe/Unix domain sockets

[vancem]

In version Version 2.2. of the runtime we created a way of controlling EventPipe outside the process by modifying an *.eventpipeconfig file. This was meant to be a stop-gap measure.

The ideal situation is for EventPipe to be controlled via a REST API. Thus you could send it commands to turn on EventSources and then ask for data chunks from it (or ask it to log it to a file instead). This can replace the file based mechanism (we avoided making this control file public precisely so we could remove support for it later.

Unfortunately, using a true HTTP port is problematic because

1. We want each process to have its own port, but you can't give HTTP endpoints names, you have to pick port numbers (and there are only a few 1000 of those available machine wide). HTTP is just not set up to have many instances of the same service on the same machine simultaneously.
2. Security is an important issue, and that is pretty complex for HTTP.
3. There is a general layering problem. Much of the HTTP logic (especially the security stuff), is high in the stack but EventPipe is very low in the stack.

After some thought, it does seem that the best solution is to make the interface 'REST-LIKE' but use the underlying OS Named Pipe functionality (which we have on all platforms), for the transport. IF we truely want HTTP Rest we could then simply make a 'multiplexer' service (a single one per machine) that handles the security aspects, bookkeeps dotnet processes as they come and go, and forward commands from the machine-wide service to the appropriate named pipe.

This issue tracks simply making EventPipe communicate through and OS named pipe (and some tooling/library on the client side for communicating with it).

[tommcdon]

@jorive can this be closed

[jorive]

Implemented here: dotnet/coreclr#23448