Reduce bisection redundancy

We have many similar CI jobs that are likely to detect the same causes for regressions, there are also cases where we detect regressions which are promptly fix before our bisections complete.

To avoid running many duplicate bisections, we already introduced the concept of “interesting commit”: we record “first bad” commits in a dedicated git repo during the first bisect, and the subsequent ones check if their bisect range contains one of the “interesting commits”, thus avoiding to bisect the full range.

This card collects improvements to these optimizations

• start bisection with current “top of branch” rather than top of branch when we detected the regression, in case the problem has already been fixed by the time the bisect job can start