Fix: fenced: Prevent segfault by not merging with in-flight fencing actions

[gao-yan]

With "pcmk_action_limit" configured to be -1 or > 1 for the fencing resource, it's possible that when reply_to_duplicates() is called, some matching commands in cmd_list are already in-flight. Previously such in-flight commands would be merged and freed. Then when a command eventually returned and st_child_done() was called, it would segfault due to use-after-free of cmd.

This commit fixes the issue by not merging with any in-flight fencing actions.

[wenningerk]

Haven't been dealing with this code for a while but wouldn't it be the better approach to simply free the one that isn't yet in-flight?
Otoh it is of course always a question if an in-flight could be something that is already lingering for a bit just without the confirmation so that the node may meanwhile have come back and would not have behaved well again so that a new fencing request actually has a reason and merging wouldn't be desired anyway.
I'm currently looking at the issue where a node comes back that quickly so that it can read about its own fencing. On the way getting that sorted out a solution for the above issue might naturally appear. I mean one that assures fences that still make sense are carried out while unnecessary double fencing due to unfortunate timing might be prevented.

[gao-yan]

Haven't been dealing with this code for a while but wouldn't it be the better approach to simply free the one that isn't yet in-flight?

If any matching one isn't yet in-flight, it will be freed with the logic in below then.

But in here, we are talking about those that are already in-flight. When the first one returns, it shouldn't merge with the other already in-flight ones anyways. We just shouldn't free/forget something that is already in-flight and has a callback registered to be called upon returning.

Otoh it is of course always a question if an in-flight could be something that is already lingering for a bit just without the confirmation so that the node may meanwhile have come back and would not have behaved well again so that a new fencing request actually has a reason and merging wouldn't be desired anyway. I'm currently looking at the issue where a node comes back that quickly so that it can read about its own fencing. On the way getting that sorted out a solution for the above issue might naturally appear. I mean one that assures fences that still make sense are carried out while unnecessary double fencing due to unfortunate timing might be prevented.

As a matter of fact, some duplicate fencing actions can be merged at the initialization stage with fenced_remote.c: merge_duplicates() in the first place. But still, it's technically possible that certain "duplicate" ones may end up executing in parallel in fenced_command.c.