Pipe objects have lost their asyncness

[Keno]

It looks like Pipe objects may have list their async-ness somewhere along the way:

julia/base/process.jl

Line 455 in b18ff77

link_pipe(stdio)

This creates a non-async (thread-blocking) pipe that's safe for spawning but not really meant for julia-side I/O. The original design here was to pass an unitialized PipeEndpoint, but that got broken in 2fdc182 (now throws an error if you attempt to do anything with it). Looking back, the uninitialized Pipe object API seems fine, but an uninitialized PipeEndpoint does not, because it switches which of the endpoints it refers to depending on whether it's initialized or not.

It would be good to look into whether we can get rid of the spawn-safe distinction. That'd probably be the easiest way to deal with this.

[Keno]

@vtjnash has indicated that he's working on libuv updates that'll change these considerations. Getting rid of the spawn-safe distinction seems infeasible. The current situation is quite bad though, since spawn-safe-pipe-io is thread blocking. The long term solution seems to be to offload pipe i/o to a worker thread if it's not async. At the very least, for 1.0, we need to think about whether we need to make any breaking changes to the API and we should make sure that the pipes we get from open are async.

[samoconnor]

Related: #24526

[JeffBezanson]

We think this is really just a bug, since it's a case that causes the process to block when it shouldn't.