Remove 2N find_commit calls from Projects::BranchesController#index

What does this MR do?

Removes unnecessary 2N-times Gitlab::GitalyClient::CommitService#find_commit calls via EE::Repository#diverged_from_upstream? from Projects::BranchesController#index only for a mirrored and/or forked project by delegating Gitlab::GitalyClient::CommitService#ancestor? to resolve branch ref to commit ID (SHA-1). This reduces 3N+1 gitaly calls to N+1 calls.

They are not required to check if a branch is diverged from upstream as git-merge-base and its Gitaly CommitIsAncestor func both support ref strings as argument.

~backstage: This also removes EE::Repository#upstream_has_diverged?, which was originally introduced in !249 (merged) (and re-organized in !6583 (merged)), but after !2919 (merged) (%10.1) through 12.8, we have never used it any more.

• search upstream_has_diverged @10.0.0-ee: https://sourcegraph.com/search?q=upstream_has_diverged+repo:gitlab.com/gitlab-org/gitlab%24%40v10.0.0-ee&patternType=literal
• search upstream_has_diverged @10.1.0-ee: https://sourcegraph.com/search?q=upstream_has_diverged+repo:gitlab.com/gitlab-org/gitlab%24%40v10.1.0-ee&patternType=literal
• search upstream_has_diverged @12.8.0-ee: https://sourcegraph.com/search?q=upstream_has_diverged+repo:gitlab.com/gitlab-org/gitlab%24%40v12.8.0-ee&patternType=literal

This updates !8495 (merged) (cf. gitlab-foss#50843 (closed)) as we do not have to make EE::Repository#commit call any more with this MR.

Calls before the MR

• 2N Gitlab::GitalyClient::CommitService#find_commit calls (N calls for refs/heads/BRANCH_NAME, yet other N calls for refs/remotes/upstream/BRANCH_NAME)
• 0...N Gitlab::GitalyClient::CommitService#ancestor? calls

Calls after the MR

• N Gitlab::GitalyClient::CommitService#ancestor? calls
• 0 Gitlab::GitalyClient::CommitService#find_commit calls

References

• https://git-scm.com/docs/git-merge-base/2.24.0
• https://gitlab.com/gitlab-org/gitaly/-/blob/v1.87.0/internal/service/commit/isancestor.go

Parts of #22851 (closed)

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• [n/a] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• [n/a] Style guides
• [n/a] Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [n/a] Label as security and @ mention @gitlab-com/gl-security/appsec
• [n/a] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [n/a] Security reports checked/validated by a reviewer from the AppSec team