conncheck: do not always remove pair in triggered check list
This patch reenables an interesting side effect that existed before commit 263c0903, when the state of a pair state in the triggered check list was changed to in-progress. Such "triggered" pairs with this state were selectively pruned from the conncheck list according to their priority in priv_prune_pending_checks(), meaning that pairs with a high priority were conserved, and quickly rechecked. Retrospectively, I suspect that this side effect was the initial motivation for changing the state of a "triggered" pair. Commit 263c0903 disabled that behaviour, for the sake of clarity, but it seems important to restore it, because these "triggered" pairs are often retriggered for a good reason, and frequently lead to a nominated pair. And loosing the opportunity to nominate a pair may be critical in controlled role when the peer agent is in aggressive nomination mode.
Showing with 20 additions and 2 deletions