Add create and edit mutations with profile layer

What does this MR do and why?

Add create and edit mutations with profile layer

Add the create/edit custom scan profile mutations, plus a util that
maps profile-level variables and trigger-level variables to the input
to send to the mutation.

Add fixtures + jest tests to cover each scenario:
- send the whole trigger set in every request
- only send enabled triggers (omitted triggers are destroyed)
- only send variables for configurable triggers
- apply profile-level variables to all enabled + configurable triggers
- apply specific trigger-level overrides to each trigger

References

• issue: [Frontend] Scan profile drawer: view, create, e... (#624191 - closed)
• direction settled on: Decide: should advanced scan configuration be p... (#627554 - closed): profile-level variables now, trigger-level overrides later
• UNCONFIGURABLE_TRIGGER_TYPES here mirrors UNCONFIGURABLE_TRIGGER_TYPES_BY_SCAN_TYPE in ee/app/models/security/scan_profile_trigger.rb

Screenshots or screen recordings

No visual changes expected

How to set up and validate locally

This adds the two mutation documents, the utility that builds their triggers input, and the fixtures and unit tests that cover it. So there is nothing to click through, and validation is the fixture run plus the jest suite.

0. git checkout 624191-fake-profile-level-variables

1. have a GitLab Ultimate licence
2. regenerate the fixtures, which exercise the real mutations against a real backend:

   bundle exec rspec ee/spec/frontend/fixtures/scan_profiles.rb

3. fixtures should be generated under tmp/tests/frontend/fixtures-ee/graphql/security_configuration/graphql/scan_profiles/:
   • security_scan_profile_create.mutation.graphql.json
   • security_scan_profile_update.mutation.graphql.json
   • ...update.mutation.graphql.per_trigger.json
   • ...update.mutation.graphql.merged.json
   • ...update.mutation.graphql.toggled_off.json

the behaviour the fixtures are asserting

4. in update with profile-level variables:
   • the same configuration comes back on every configurable trigger
   • GIT_PUSH_EVENT comes back with no configuration
5. in update with per-trigger variables, check that:
   • a value set on one trigger stays on that trigger and does not leak to the others
6. in update with both profile-level and trigger-level variables, check that:
   • the merge is key by key, so a trigger-level value overrides only the key it sets
   • keys the trigger did not set still come through from the profile level
7. in update with a trigger toggled off, check that:
   • the omitted trigger is absent from the response

then run jest tests that use the fixtures

yarn jest ee/spec/frontend/security_configuration/graphql/scan_profiles/map_scan_profile_variables_spec.js

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.

Related to #624191 (closed)