Fix: https://github.com/ClusterLabs/pacemaker/pull/3331

On Fedora 38/39, the issue starts with commit bc91cc5 (Pacemaker 2.1.0). Previously, mon_cib_connection_destroy() removed all stonith client notifications and disconnected the client, but it didn't delete the client object. As of that commit, it also deletes the client object.

Not reproducible on RHEL 9.3 with the latest packages. Also not reproducible on Fedora 37.

On second thought, although the ref count might be the easiest way to fix this, it would be totally reasonable to say "no function that's registered as a stonith notify callback should ever free the stonith_t object."

I need to verify this, but here's what I think is happening:

1. Mainloop destroys stonith API connection, calling stonith_connection_destroy() on the stonith client.
2. The stonith client sends out T_STONITH_NOTIFY_DISCONNECT notifications via foreach_notify_entry() -> stonith_send_notification().
3. One notification triggers crm_mon.c:mon_st_callback_display() (or event()), which calls mon_cib_connection_destroy().
4. mon_cib_connection_destroy() calls stonith_api_delete(), which calls stonith_api_free() and destroys the entire client object.
5. Control returns to stonith_send_notification() and foreach_notify_entry().
6. One of the further attempts to access members of the stonith client object causes a segfault, since the object and all the members that it owns have been freed.

I've reproduced this on 2.1.0, 2.1.2, and 2.1.7, so it doesn't appear to be a regression. Additionally, it only happens at shutdown, so there's no tangible impact except that it won't reconnect when the cluster starts back... which is not great.