fix: Bound repeated thread-pool loop failures

[mvanhorn]

Fixes #17165

---

Add a 👍 reaction to pull requests you find important.

[straight-shoota]

This is not a trivial change. Could you explain the reasoning for this patch? What exactly happens when reaching the failure threshold? Why did you choose this fix and would there be alternatives?

While putting a limit doesn't seem like a bad idea, it only treats a symptom and doesn't fix the underlying issue of #17165

[ysbaddaden]

Thanks for the attempt, but:

1. The main thread musn't return as it would invalidate the main fiber's stack and lead to segfaults;
2. On Windows, no thread must return as it could block pending async operations.

Still, the rescue/print error then keep looping was a bad choice. The loop must never fail. If it does fail, we must just panic, not even retry, unless maybe in the sure case that we know there's nothing (no attached scheduler or scheduler being attached in parallel, no lost fiber, no pending async op, not the main thread, ...).

[mvanhorn]

Dropped the retry entirely: the loop now exits after printing the error, matching Crystal::Scheduler#fatal_resume_error. Nothing returns from enter_thread_loop any more, so both the main-fiber stack and the pending Windows I/O concerns go away. That collapses this to a one line change, and I removed the spec I had added since it only covered the retry path that is gone.