Introduce concept of Merge Request Violation

Why are we doing this work

To implement the next iteration of the "Compliance Dashboard" we should store compliance violations such as a failure of separations of duties.

Currently this information is generated on-the-fly but this proposal is to create a new domain model: MergeRequests::ComplianceViolation which encapsulates information about a single failure of an MR to adhere to a particular hard-coded rule.

Examples of these include:

• When an author approves their own MR.
• When a committer approves their own MR.
• When an MR is merged with an X% drop of code coverage.

We should implement the following:

• The new domain model as above.
• Implementation of the new violation objects when an MR is merged.
• A GraphQL implementation to allow the group-level querying of data for a group's merge requests.

Implementation plan

• backend - Introduce new domain model - !74290 (merged) : workflowin review
• backend - On MR merge, save a list of MR violations that occured at the point of merging.
• backend - Add GraphQL type MergeRequestComplianceViolationType available as a traversal from MergeRequest (maybe?).

Proposed Data Structure

• MergeRequest has zero or more MergeRequests::ComplianceViolation
• Before merging, a MergeRequest should have NO violations.

Column Name	Type	Example	Notes
merge_request_id	bigint (foreign key on merge_requests.id)	1	Which MR?
violating_user_id	bigint	(foreign key on users.id)	1
reason	enum	approved_by_author: 0, approved_by_committer: 1, approved_by_insufficient_users: 2	What caused the violation? We can map each of these to a hard-coded severity as defined by us.