Fix async read issue with anonymous PipeStream

[xoofx]

Hey,
I encountered a bug that took me quite some time to find out.
I was launching multiple msbuild concurrently (e.g 20) on separated threads from the same process and using Anonymous pipes was making the application taking 40s to complete while the same operation should take no more than e.g 1s in total.
It turns out that PipeBuffer was using ReadAsync on a pipe stream which seems to be not supported actually, hence the weird behaviors.

For more details:

• See issue AnonymousPipeClientStream.ReadAsync does not seem to support cancellation dotnet/runtime#23638
• Doc https://docs.microsoft.com/en-us/windows/win32/ipc/anonymous-pipe-operations
• "Asynchronous (overlapped) read and write operations are not supported by anonymous pipes"

I still keep around the cancellationToken.IsCancellationRequested as FillFromStream is called in a loop in the end, so still worth to have it around.

[daveaglick]

Nice detective work! It's interesting that the docs for AnonymousPipeClientStream don't actually mention this limitation. In fact, it's worse because those docs make it sound like it's actually supported:

Exposes the client side of an anonymous pipe stream, which supports both synchronous and asynchronous read and write operations.

I suppose there might be a platform difference here - non-Windows platforms where the underlying anonymous pipe is implemented differently may not exhibit the same limitations. Rather than speculate or add OS checks, your solution seems simplest and safest though.

I'm going to follow-up with a documentation issue on those AnonymousPipeClientStream docs too - even though it's niche, seems like a good thing to have called out.