fix: events leak that can occur if allocation fails

[Green-Sky]

rare in practice, found by fuzzing

---

This change is 

[nurupo]

Reviewed 40 of 40 files at r1, all commit messages.
Reviewable status: complete! 1 of 1 approvals obtained

[Green-Sky]

Not sure how we should fix the mallocfail test. the send message autotest times out, be cause the event fails to allocate and thus gets dropped.

[nurupo]

Well, the allocation failure is propagated to the test code via tox_events_add()'s return value, so the test could notice the failure and change its behavior accordingly. Simply changing the test to succeed and terminate on the first allocation failure it encounters seems wrong though -- the test tests sending messages, no message got sent, yet the test succeeded. It clearly should still fail in this case. But as far as testing with mallocfail, we want the test to succeed and we want to test the entire code with mallocfail, but just exit the test with success on the first allocation failure. The obvious way to achieve all of this that comes to mind is changing all the tests to keep re-trying to allocate on all possible allocation failures as mallocfail does succeed eventually. Have the retries be limited to some number though, just to avoid infinite loops in case it never succeeds due to some bug or something. Might also want to have that retrying behavior under a flag that is turned on only when testing using mallocfail, as without mallocfail we would want the tests to fail right away and not waste the time retrying to allocate.

[nurupo]

Actually, scratch that. Reading mallocfail's README, the intended use is to not modify the code to accommodate the use of mallocfail, but to keep re-running it with mallocfail many times until no new entries are added to mallocfail's hashes file, at which point all mallocs will succeed and the test should succeed too, keeping note of unusual terminations/crashes along the way.

[Green-Sky]

for reference #2783 was a fix specifically for the ci fail.