Add categories to security attributes removal re-sync process

What does this MR do and why?

As described in #596003 (closed), when the security attribute is removed from the project, the MR was still blocked. In MR !230801 (merged) added a trigger to re-sync policies when security attributes are removed for policies with the business_impact scope .

In this MR we are extending the re-sync trigger for the others security categories policy scope. During the tests, the bot comment was not updated. I will investigate and work in a fix in a follow-up MR.

References

Related to: #596003 (closed)

How to set up and validate locally

1. Create a new group
2. Go to Secure > Security configuration
3. Select any category other than Business Impact. E.g Application
4. Click in Create attribute
5. Add a name and description E.g Finance
6. Click in Save changes
7. Create a new project
8. Add a .gitlab-ci.yml file to the project with the content:

include:
- template: Jobs/SAST.gitlab-ci.yml

9. Add an empty test.rb file
10. Go to Secure > Security configuration
11. Select Security attributes
12. Click on Edit project security attributes
13. Select the attribute created in the previous steps. E.g: Finance
14. Click in save changes
15. Go back to the group created on step 1
16. Go to Secure > Policies
17. Click on New policy
18. Select Merge request approval policy
19. Create a policy to block new vulnerabilities on Finance projects
20. Get the security_attribute id

category = Security::Category.where(template_type: "application").where(namespace: Group.last)
security_attribute_id = Security::Attribute.where(security_category: category).where(name: "Finance").first

20. Create a policy like

approval_policy:
  - name: Test
    description: ''
    enabled: true
    rules:
      - type: scan_finding
        branches: []
        vulnerabilities_allowed: 0
        severity_levels: []
        vulnerability_states: []
        scanners:
          - type: sast
            vulnerabilities_allowed: 0
            severity_levels:
              - critical
              - high
            vulnerability_states:
              - new_needs_triage
            vulnerability_attributes:
              false_positive: false
    policy_scope:
      application:
        including:
          - id: <security_attribute_id>
    actions:
      - type: require_approval
        approvals_required: 1
        role_approvers:
          - developer

21. Click on Create new project with the new policy
22. Merge the MR to add the policy
23. Go back to the project created in step 7
24. Create a MR adding the file vuln.rb with the content

class RunScript
  def run_script
    system("cat #{params[:path]}") 
  end
end

25. Verify the MR is blocked

26. Go to Secure > Security Configuration
27. Select Security attributes
28. Click on Remove attribute
29. Verify the MR does not require approval anymore
30. Repeat the steps 5 to 8 to add the security attribute again
31. Verify the MR is blocked again

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.