refactor: decouple worker threads from non-worker threads

[Alliballibaba2]

This PR refactors how threads are started and is meant as a step towards scaling threads at runtime.

How worker threads are currently started:

Currently, worker threads are started from regular threads via sending a special request
to ServeHTTP. The disadvantage here is that between sending the special worker request
and receiving it, we are losing control over which thread becomes a worker thread.
Worker threads and regular threads are inevitable coupled to each other.

How worker threads are started with this PR:

This PR decouples worker threads from regular threads and makes the php_thread struct
a wrapper around the thread's lifetime.

A 'PHP thread' is currently just a pthread with its own TSRM storage (this doesn't
necessarily have to be tied to a real thread in the future as discussed in #1090).

The thread starts, does some work in a loop and then stops. This PR makes it possible
to configure these 3 lifetime hooks from the go side via the php_thread struct:

• onStartup: Right before the thread is ready (once)
• onWork: The actual work the thread does (in a loop)
• onShutdown: Right before the thread is stopped (once)

This allows re-using the same mechanism for regular threads as well as worker threads.
It also makes it easier to create other potential types of threads in the future
(like 'scheduled workers' or 'task workers').

Additionally, it now would also be possible to grab an 'idle thread', exchange it's hooks and
turn it into a different type of thread at runtime without stopping the underlying thread.
(This PR doesn't go that far though)

[Alliballibaba2]

Hmm that segfault is interesting, It's probably not fully safe to execute a PHP script while calling (void)ts_resource(0);, I'll adjust the logic.

[AlliBalliBaba]

I also have a branch forked from this one which adds 3 endpoints to the admin api

/frankenphp/workers/restart
/frankenphp/workers/add
/frankenphp/workers/remove

The restart endpoint definitely makes sense and does the same thing as the watcher. The /add and /remove endpoints add and remove a thread from a worker. This works pretty well and I mainly added this for testing. While it's pretty cool to do this at runtime I'm not sure yet if this is something we want to expose.

Btw the alpine/arm docker pipelines have timed out after 6 hours (would it make sense to skip them until release for now?).

[AlliBalliBaba]

I also want to try if it's safe to boot a thread at runtime (might be necessary for #1216). BOoting led to segfaults when I tested it previously, but it might be safe after this opcache fix.

[withinboredom]

Btw the alpine/arm docker pipelines have timed out after 6 hours (would it make sense to skip them until release for now?).

Organizations can now apply for the arm beta from GitHub (at least, it is offered in my org). Just a matter of time until we can run these on arm machines instead of emulating them.

But, LGTM.

[dunglas]

@withinboredom do you have the link for the wait list?

[withinboredom]

do you have the link for the wait list?

In the organization action runner settings, there was just a button to enable them. I don't see it on any of the free orgs I have admin access to, just the paid one.

[dunglas]

Sounds very very good! I left some minor comments, and there are some TODOs to fix, then we'll be ready to merge.

[AlliBalliBaba]

Something else I've been wondering:

When using the watcher, should an initial worker startup failure panic also be prevented?

[dunglas]

Indeed, good idea. When watchers are enabled, we should never panic IMHO.

[dunglas]

Thank you @AlliBalliBaba!