feat(net): named pipe support via Deno.pipe

[CyanChanges]

close #10244

Support Named Pipes via Deno.pipe

todos

• verify if work in windows (I have no Windows dev machine rn)

• update deno_node to use Deno.pipe for Windows
  - close Not implemented: Pipe.prototype.connect #28332
  - close Uncaught Error: Not implemented: Pipe.prototype.listen - Windows #25867

• type definitions

• add tests

[CyanChanges]

Confirmed!
Works in Windows now!

(I spent a total of $5 on GCP for a Windows machine 😢)

[CyanChanges]

Working on the Windows support for the deno_node PipeWrap .

[CyanChanges]

Help Wanted

I encountered an issue when working on the node compat:

import * as net from 'node:net'

// I have a server listening on this pipe
// ```ts
// const pipe = Deno.pipe.listen({ path: "\\\\.\\pipe\\mypipe1", kind: "windows", pipeMode: "byte" })
// const ab = new Uint8Array(32)
// await pipe.read(ab); // didn't resolve, it resolve to null after the other side closed :skull: 
// ```
const conn = new net.createConnection({ path: "\\\\.\\pipe\\mypipe1" }) 
conn.write("something") // `true`, but do nothing

// if you await here, it will stuck here
/*await */ Deno[Deno.internal].core.write(
  /* 
  If you createConnection immediately after start, 
  the pipe resource should be assigned a rid of 3
  */ 
  3, 
  new TextEncoder().encode("test")
)

I tried to write it directly via Resource Id, but the promise never resolves,
instead, it rejects after the resource closed 😢

The read still works tho, no idea why.

The Problem Only Appear In Windows (Because the issue aim to support node:net.createConnection when using Windows with named pipe)

[nathanwhit]

nice, the implementation looks reasonable to me. I'm less sure about the public API changes and the pipe_wrap changes for windows. The pipe_wrap changes seem ok at a glance.

I think the team will have to discuss the new API, and then go from there.

[nathanwhit]

Why wait to connect until read/write is called? I assume it's related to the todo in new_server?