Multiplex concurrent nsgi_handle calls onto Fibers with a Fiber::Scheduler

[himura467]

Goal

Handle many concurrent nsgi_handle calls efficiently by multiplexing them onto Fibers inside the single Ruby VM.

Tasks

• Fiber-per-request dispatch: each dequeued job runs in its own Fiber under a Fiber::Scheduler, so I/O waits in app code yield instead of blocking the VM thread
• Minimal built-in Fiber::Scheduler (io_wait, kernel_sleep, block/unblock) driving the reactor loop, including the job-queue wake pipe
• Pluggable scheduler: allow swapping in async/io-event instead of the built-in one (loose coupling — the app contract must not depend on which scheduler runs)
• Backpressure: bound in-flight jobs so a slow app degrades gracefully instead of piling up blocked host threads

[himura467]

Implemented in feaec63 (PR #9). The VM thread now runs a Ruby-side reactor (NSGI.__run) under NSGI::Scheduler, a minimal Fiber::Scheduler implementing io_wait, kernel_sleep, block/unblock (thread-safe via a self-wake pipe, so Thread::Queue handoffs from background Ruby threads work) and fiber. Host threads push jobs and wake the reactor through a pipe; every job runs in its own Fiber.

Measured interleaving in the mock host: 32 concurrent 50ms-sleeping requests complete in ~220ms (theoretical floor 200ms; fully serialized would be 1.6s).

• Pluggable: assign NSGI.scheduler from the app file to swap in another conforming scheduler; the app contract (SPEC.md section 4) does not depend on which one runs.
• Backpressure: the primary mechanism stays the synchronous host threads themselves; additionally NSGI_MAX_PENDING bounds the queue and rejects overflow with a static 503 before dispatch.
• Fault tolerance: the reactor rescues per iteration, and if it ever exits, the bridge degrades to serving static 500s instead of hanging blocked host threads.