Update system note text for relating blocking issues & epics

What does this MR do and why?

MR fixes the misleading system notes that are getting created after an issue/epic got connected using block/blocked_by link to another issue/epic. Current notes (example: marked this XXX as related to YYY) are getting extended by providing more details on the exact type of a link that is getting created (XXX blocks YYY/YYY blocked by XXX).

Notes message summary

Issuable	Action	Link type	Message before MR	Message after MR	Changed
Issue	Add	blocks	marked this issue as related to #XXX	marked this issue as blocking #XXX	✅
		blocked_by	marked this issue as related to #XXX	marked this issue as blocked by #XXX	✅
	Remove	blocks	removed the relation with #XXX	removed the relation with #XXX	🚫
		blocked_by	removed the relation with #XXX	removed the relation with #XXX	🚫
Epic	Add	blocks	marked this epic as related to &XXX	marked this epic as blocking &XXX	✅
		blocked_by	marked this epic as related to &XXX	marked this epic as blocked by &XXX	✅
	Remove	blocks	removed the relation with &XXX	removed the relation with &XXX	🚫
		blocked_by	removed the relation with &XXX	removed the relation with &XXX	🚫

(Regarding the table structure, I was expecting that empty cells get merged with non-empty ones above them, for colspan-like effect ¯_(ツ)_/¯)

Notes

• Data migration
  • Existing system notes are not migrated
• Scope of this MR includes features that are part of the EE distribution
  • Blocking issues
  • Blocking epics
• In the beginning I was considering another solution
  • Going that way would result in less code written and less new methods (no need in EE::SystemNotes::IssuablesService.block*_issuable)
  • But after starting to go into that direction I got a feeling that it will be safer to go with the current one
  • Here I tried to summarize current implementation (comparing it with the first version) :
    • Pros
      • Extends flow (instead of modifying the behaviour of the existing component SystemNotes::IssuablesService.relate_issuable)
      • Doesn't complicate the notes message building logic
        • Technically blocks/blocked_by are subtypes of the same relation as relates_to, though the order plays an important role there (compared to relates_to). So they can't be treated the same way as with relates_to, where #{issuable} relates to #{noteable} is the same in both directions.
    • Cons
      • Similar code in 2 places (EE::SystemNotes::IssuablesService.block*_issuable)
      • More LOC

Screenshots or screen recordings

Issues

Type of relation	Before	After
blocks		The text is outdated here, you can find new one in the notes message summary table ☝
blocked_by

Epics

Type of relation	Before	After
blocks		The text is outdated here, you can find new one in the notes message summary table ☝
blocked_by

How to set up and validate locally

Prerequisites

• Blocking issues enabled
• Blocking epics enabled

Web

1. Create 2 issues (#A and #B)
2. Connect #A with #B as blocks/blocked_by
3. Take a look at system notes

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Closes #365048 (closed)