Add ability to Trust a user to create possible spam from an Abuse report

What does this MR do and why?

UI-side follow-up to !123430 (merged) and part of https://gitlab.com/gitlab-org/gl-security/security-engineering/security-automation/spam/spamcheck/-/issues/17

This is the first MR in a series that aims to split up !125042 (closed) into smaller, more manageable MRs. Follow up MRs will:

• Add tab to the /admin/users dashboard to see users who are trusted, and allow admins to trust/untrust users from that dashboard
• Add ability to trust/untrust users from the /admin/spam_logs dashboard

Adds UI elements to allow admins to explicitly trust users for purposes of creating issues, notes, snippets, etc. that are detected to be possible spam.

We use UserCustomAttributes to indicate when a user is trusted to create possible spam.

This MR does not add the ability to untrust a previously trusted user from the abuse reports dashboard to stay consistent with the other actions available. Being able to untrust a user will be in a follow-up MR.

Follow-up MRs:

• !131812 (merged)
• !132402 (merged)

Database review

app/services/user/untrust_service.rb uses #delete on a user's UserCustomAttributes that have the trusted_by key. Per our guidelines, the query is:

DELETE FROM "user_custom_attributes" WHERE "user_custom_attributes"."user_id" = 6 AND "user_custom_attributes"."key" = 'trusted_by' 

and the query plan is:

ModifyTable on public.user_custom_attributes  (cost=0.56..3.45 rows=0 width=0) (actual time=6.057..6.058 rows=0 loops=1)
   Buffers: shared read=4
   I/O Timings: read=6.013 write=0.000
   ->  Index Scan using index_user_custom_attributes_on_user_id_and_key on public.user_custom_attributes  (cost=0.56..3.45 rows=1 width=6) (actual time=6.054..6.055 rows=0 loops=1)
         Index Cond: ((user_custom_attributes.user_id = 6) AND ((user_custom_attributes.key)::text = 'trusted_by'::text))
         Buffers: shared read=4
         I/O Timings: read=6.013 write=0.000

The results are:

  
Time: 7.041 ms  
  - planning: 0.903 ms  
  - execution: 6.138 ms  
    - I/O read: 6.013 ms  
    - I/O write: 0.000 ms  
  
Shared buffers:  
  - hits: 0 from the buffer pool  
  - reads: 4 (~32.00 KiB) from the OS file cache, including disk I/O  
  - dirtied: 0  
  - writes: 0  

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Log in to your GDK as an admin
2. Navigate to admin/abuse_reports
3. Click on the first abuse report
4. Click the Actions button
5. In the Action menu, select Trust user
6. Click Confirm
7. Go to the user's admin panel /admin/users/<username> and verify that trust_by appears as a custom attribute at the bottom of the user's information.

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.