Support Sync and Async on non-blocking fibers via Fiber.blocking.

[samuel-williams-shopify]

Summary

Sync and Async could not be invoked from a non-blocking fiber that has no scheduler — e.g. inside an Enumerator block or a bare Fiber.new { ... }.resume. Doing so raised:

RuntimeError: Running scheduler on non-blocking fiber! (lib/async/scheduler.rb)

Minimal reproduction:

e = Enumerator.new do |yielder|
  yielder << Sync { fetch_something }
end
e.next   # => RuntimeError: Running scheduler on non-blocking fiber!

This shows up whenever Sync/Async is reached beneath a bare non-blocking fiber (job runners, Enumerator, other libraries), and previously required an awkward caller-side workaround such as Fiber.new(blocking: true) { Sync { ... } }.resume.

Change

Run the reactor within Fiber.blocking (kernel/sync.rb, kernel/async.rb). When there is no current task and no scheduler, the reactor is started inside Fiber.blocking { ... }, so the event loop always runs on a blocking fiber — on the current fiber, preserving fiber identity and fiber-locals (no extra fiber is spawned). Task fibers still terminate normally, so control returns to the reactor loop via the resume chain as before.

Tests

• test/kernel/sync.rb — a new with "a non-blocking fiber" context covering: running the scheduler on a non-blocking fiber, return values, asynchronous work with blocking operations (barrier + semaphore), exception propagation, fiber-storage preservation, nested Sync, use within an Enumerator (value yielded after Sync returns), and the clean-failure case when trying to yield to the enumerator from inside the block.
• test/kernel/async.rb — running Async on a non-blocking fiber, running work to completion, and passing options through.

Notes

This handles the common case, where the reactor fiber is entered via resume (which covers Enumerator, bare Fiber.new { ... }.resume, and typical job runners). The case where the reactor fiber is entered via Fiber#transfer and is off the resume chain (e.g. owned by another transfer-based scheduler) is not addressed here — it requires the Ruby-level fix tracked in https://bugs.ruby-lang.org/issues/20081, since fiber termination needs to return control to the transferring fiber.