pkg/bisect: filter out obviously unrelated crash types

[a-nogikh]

Random lost connection crashes seem to regularly derail the bisection process. A recent example:

https://lore.kernel.org/all/[email protected]/T/#ef85d48463732e6ac91be891e77e9bf90ba88ddee

In the case above, the problems began here:

testing commit b8c8ba73c68bb3c3e9dad22f488b86c540c839f9 gcc
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
kernel signature: 2421239c9ec8055b97da598fa4ac0a54ba5b001988adf334fe6b4cd3791ada98
run #0: crashed: lost connection to test machine
run #1: crashed: lost connection to test machine
run #2: OK
run #3: OK
run #4: OK
run #5: OK
run #6: OK
run #7: OK
run #8: OK
run #9: OK
representative crash: lost connection to test machine, types: [UNKNOWN]
# git bisect bad b8c8ba73c68bb3c3e9dad22f488b86c540c839f9

We do have a lower bound on the number of observed crashes to conclude the step to be a bisect bad:

syzkaller/pkg/bisect/bisect.go

Line 831 in cd6fc0a

wantBadRuns := max(2, (total-infra)/6) // For 10 runs, require 2 crashes. For 20, require 3.

But apparently it's not enough. We should be also looking at least at the correspondence of the observed crash types to the crash type of the original bisected issue.