Improve the performance of updating the index after force push
Related to !10538 (merged) where we start reindexing from scratch after a force push we may find some cases for very large repos that a single force push could cause indexing to grind to a halt.
We hypothesise this is what contributed to a customer issue in https://gitlab.zendesk.com/agent/tickets/132478 .
As such we may prefer to go with an approach that more efficiently determines where to start reindexing from.
Given force pushes are most likely occurring for recent commits in the default branch it could be assumed that it's likely only a few commits that need to be deleted and reindexed. It might be feasible to take the new HEAD of the default branch and find it's most recent shared commit with the previous HEAD of the default branch. This is assuming that we still have the HEAD of the previous branch. If we had that and could walk up parents on both branches until they share a common ancestor then we only need to delete the commits we walked on the previous default and only need to index the commits we walked on the new default branch.