Fix use-after-free triggered by fast actor reaping when the cycle detector is active

[dipinhora]

The logic in the actor run and the cycle detector work together to enable fast reaping of actors with rc == 0. This relies on atomics and protecting the relevant areas of logic with critical sections. This logic unfortunately suffered from a use-after-free bug due to a race between the cycle detector receiving the block message and destroying the actor and the actor cycle detector critical flag being release as identified in #4614 which could sometimes lead to memory corruption.

This commit changes things to remove the need to protect the logic with critical sections. It achieves this by ensuring that an actor with rc == 0 that the cycle detector knows about will never be rescheduled again even if the cycle detector happens to send it a message and the cycle detector is free to reap the actor when it receives the block message. The cycle detector ensures that the actor's message queue is empty or that the only messages pending are the expected ones from the cycle detector so it can safely destroy the actor.

resolves #4614

[dipinhora]

@redvers it would be ideal if you're able to confirm that this PR resolves your segfault from #4614..

@SeanTAllen it would be ideal if you're able to review the logic changes to confirm i didn't screw anything up as i believe you're the last person to touch this code and likely know the nuances/edge cases that need to be handled best..

[ponylang-main]

Hi @dipinhora,

The changelog - fixed label was added to this pull request; all PRs with a changelog label need to have release notes included as part of the PR. If you haven't added release notes already, please do.

Release notes are added by creating a uniquely named file in the .release-notes directory. We suggest you call the file 4616.md to match the number of this pull request.

The basic format of the release notes (using markdown) should be:

## Title

End user description of changes, why it's important,
problems it solves etc.

If a breaking change, make sure to include 1 or more
examples what code would look like prior to this change
and how to update it to work after this change.

Thanks.

[SeanTAllen]

@redvers it would be ideal if you're able to confirm that this PR resolves your segfault from #4614..

@SeanTAllen it would be ideal if you're able to review the logic changes to confirm i didn't screw anything up as i believe you're the last person to touch this code and likely know the nuances/edge cases that need to be handled best..

@dipinhora I will review and I appreciate your believing that I am still familiar with this code that tortured me a few years ago. I especially appreciate at it, after I believe you found a bug in code I wrote (at least I remember it as "I wrote").

[SeanTAllen]

This hurts my brain. I think it is good. But I'd love to have @redvers throw lots of requests at it.

Writing the code to be removed also hurt my brain. I remember Dipin and I spending A TON OF TIME on it. A metric shit ton of time.

[dipinhora]

This hurts my brain. I think it is good. But I'd love to have @redvers throw lots of requests at it.

Writing the code to be removed also hurt my brain. I remember Dipin and I spending A TON OF TIME on it. A metric shit ton of time.

i guess it all rests on @redvers's shoulders.. 8*P

[redvers]

I definitely have the easiest job here. ;)

[redvers]

Yup, 15.5 Millions requests later, no SEGV.