Copy related issues when moving an issue or marking duplicates

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Description

• When moving an issue or marking duplicates, copy over related issues.
• When Issue A is moved to Issue B, what happens behind the scenes is that Issue A is closed, and Issue B is created.
  • Suppose A has a related issue, C.
  • After the move, C should now be related to B.
• When A is marked as a duplicate of B, A is closed.
  • Suppose A has a related issue, C.
  • After the move, C should now be related to B. Marking related should be idempotent.
• Even if the user doing the moving or duplicate marking may not have permissions to access C, it still happens behind the scenes, so that the new related issues relationship is established in the system, even though that user can't see it. (But other users may see it.) An example of this occurring is C being in a project that the user doesn't have access to.
• Add system notes for the new related issues.

Original description

For example this post-mortem: https://gitlab.com/gitlab-com/infrastructure/issues/3850 has 9 related issues. All but one are listed as closed.

In particular these are both listed as closed:

Update to Postgres 9.6.8 in production #3851
(consider) Rebuilding trigram indexes in production database #3852

However looking more carefully you see

Yorick Peterse @yorickpeterse mentioned in issue database#14 4 days ago 
Yorick Peterse @yorickpeterse mentioned in issue database#15 4 days ago

And in fact those two issues are the two "closed" issues above which were moved to the database project.

This makes the "related issues" section hard to interpret. It looks like they've all been closed but in fact several of them are still open just having been moved.