conncheck: do not always remove a pair when it is in the 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 ignoring the possibility to nominate a pair may be critical in controlled role when the peer agent is in aggressive nomination mode.