Confirm runtime events ring is still active after callback

[kayceesrk]

We need to check whether the ring is still active after a callback. It may be that the ring was destroyed during the callback execution. If this were the case, the subsequent call to write_to_ring would crash.

[sadiqj]

Good find and the fix seems correct, thanks!

[ghost]

Makes sense to me. Thanks for looking into this.

[gasche]

My understanding:

1. It's a bit weird to silently stop at this point, we called a user-provided feedback and we silently ignore its result. But there is no clearly better choice. (In particular, failing with an exception would not be very nice either, because it would be an asynchronous exception that is not due to the emitted event itself.)
2. An alternative would be to reference-count the number of people planning to write to the ring, and wait until that count drops to 0 before actually closing the ring. But this is more work to implement, and it makes the programming model weird -- when someone asks to close/shutdown the runtime-events machinery, they get a return but the ring may remain written to for an arbitrarily long time, possibly forever if a writing thread is deadlocked.

[kayceesrk]

Agree with your assessment. I would expect the guard added in this PR to only trigger rarely in racy programs where some domain is writing to the ring while another domain is actively terminating the program. Given that the program is terminating, it is better to take the simpler route of dropping the write. Tools like perfetto can already deal with "missing" events, such as having a span open event with a corresponding span close event.

[kayceesrk]

The data race in test_dropped_events is fixed in #13529.

[kayceesrk]

@gasche do you have any objections to merging this PR?

[gasche]

None. (I haven't looked at this enough to have formed an opinion, and I'm happy to trust the process :-)

[sadiqj]

Great. Merging! Thanks @kayceesrk

[dra27]

Cherry-picked to 5.3 in ebc3c13. Is this wanted for 5.2.1 as well?