Add Fiber-Based Non-Blocking IO Worker Support

[jujustayfly]

Add async execution support with fiber-based concurrency

Feature Overview:
Adds hybrid execution mode combining threads with fibers for higher concurrency on IO-bound jobs. Jobs can now yield during database queries, HTTP requests, and other IO operations, allowing other jobs to execute concurrently within the same thread.

Key Features:

• Hybrid architecture: Multiple threads each running multiple fibers (e.g., 4 threads × 10 fibers = 40 concurrent jobs)
• Async-compatible jobs: Jobs using async gems automatically benefit from non-blocking IO
• Automatic fiber scheduling: PostgreSQL queries, HTTP requests, and file operations yield control when using fiber scheduler
• Backward compatibility: Existing jobs run unchanged in thread-only mode

Configuration:

Gouda.configure do |config|
  config.use_fibers = true
  config.fibers_per_thread = 10
  config.worker_thread_count = 4
end

Performance Benefits:

• IO-bound jobs: 10x+ throughput improvement for jobs with database queries, API calls, file operations
• CPU-bound jobs: No performance penalty (can disable fibers per queue)
• Memory efficient: Fibers use ~4KB vs threads at ~8MB each

Safety Features:

• PostgreSQL isolation level checking: Prevents segfaults with incorrect Rails configuration
• Graceful fallback: Jobs work in both fiber and thread modes
• Per-job execution tracking: Clear identification of fiber vs thread execution context

Implementation:

• Single Worker class supporting both execution modes
• Unified sleep/polling mechanism for threads and fibers
• Consolidated test suite and documentation

[julik]

Epic stuff! It does feel like we could merge the two workers and have a wrapper which either uses Async or not, and also sets the appropriate isolation level - instead of having two separate worker modules.

Can't wait to try this with the sync job!

[jujustayfly]

@julik Thanks for the insight! Implemented all your suggestions. Feel free to review again or we can discuss the last details on a call

[svanhesteren]

Hey cool stuff! I like the current implementation. Sorry it took so long! Since you tested this thoroughly I assume the comments I made are not an issue (yet).

I like the idea of running both kind of workers for different kind of jobs. This gives us a bit more control in optimizing for certain jobs. Are there any jobs we have currently that would benefit from sticking to classic thread-only execution?