Potential fix for #10322

If I'm understanding what happens when scheduler pollset migration gets triggered: once the state->count++ > 10, we migrate the "hot fd" to the scheduler pollset.

However, the state->count++ is global, so if there are multiple processes all calling socket:accept at the same time, then state->count++ > 10 could be triggered almost immediately.

For things like socket:recv, this generally would work as expected since there is typically one process calling this in a loop.

However, for socket:accept, it's more of a common practice to have multiple processes all trying to accept inbound connections.

If all of that's correct, then this is my assumption:

• OTP 27: Direct message delivery from the I/O thread(?)
• OTP 28: Process signals, sent from the normal scheduler thread(?)

The change here is to add a state->last_select_pid field and reset the state->count = 0 if we detect that the process has changed between calls to enif_select.