Inclusion pruning tweaks

[Overkillus]

In follow-up to #1518

Adding extra tests for inclusion pruning. Primarily focusing on various cases surrounding candidates included in different forks (with different relay parents).

All cases fall into a few buckets based on 3 degrees of freedom - number of candidates, number of blocks (height), number of forks + extra case for pruning multiple heights at once.

The last case of pruning multiple at once has a case that panics in debug due to a potential oversight (@eskimor) but should not cause any inconsistencies or stalls when deployed. Although debug incorrectly labels it as an inconsistency.

It can happen that when the same candidate is added into multiple forks but not the same height and we prune both of those heights at the same time we can erroneously fail the debug assert and trigger the debug inconsistency log. It happens because we prune the candidate yet we still have another copy of it in the stale iterator. This case while rare is fully expectable and natural.

Added small tweak to the original pruning function to disregard stale candidate duplicates which should keep the same behaviour overall but handles this edge-case more gracefully.

[eskimor]

Ok, this is some test coverage now. You do your name justice ;-)

[eskimor]

Very good catch! Given that this should indeed be pretty rare, I would avoid the inefficiency of collecting into a HashMap and instead remove the debug assert and the debug log.

Really not a strong concern though, also with asynchronous backing this can happen more often.

[tdimitrov]

Good work @Overkillus!

i've pushed a change fixing the comment visualisation in github (the tab gets messed up for some reason and the first row looks off). Feel free to revert if you don't like it.