Improve approach for linking merge requests to issues for cycle analytics calculations

The Plan metric in cycle analytics is not helpful. Once an issue is triaged in some way (Issue stage) is begins the Plan stage, however this consistently shows an impossibly short period of time in GitLab projects, and is likely the same for customers.

Project	gitlab-org/gitlab-ce	gitlab-org/gitlab-ee	gitlab-org/gitaly
Issue	6 mins	< 1 min	2 mins
Plan	4 days	6 days	7 days

Also when viewing the list of issues that are being considered, gitlab-ce and gitlab-ee report only one issue, while gitaly says We don't have enough data to show this stage.

The issue is caused by first_mentioned_in_commit_at only being set if the issue is explicitly mentioned in a commit message.

Proposal

Update first_mentioned_in_commit_at to be set in the following two situations:

• a commit message is pushed explicitly mentions the issue (existing)
  • sets first_mentioned_in_commit_at to the authored date of the commit
• when a merge request is merged and explicitly closes the issue
  • sets first_mentioned_in_commit_at to the authored date of the first commit in the merge request

The merge request widget allows issues to be closed by mentioning the issue in a commit message or in the merge request description. The cycle analytics logic should be consistent.

Links