Migrate data to system_access_group_microsoft_applications

What does this MR do and why?

Migrates data from SystemAccess::MicrosoftApplication to SystemAccess::GroupMicrosoftApplication . This is to enable the table to be split between instance application records for instance-wide SAML sync, and per-group application records for group-based SAML sync. This way we can shard the data appropriately for Cells.

• Adds a migration to copy all group-SAML records to the new table
• Updates logic to write changes to both tables during the transition
• Adds feature flag to control which table is read from by application controllers and SAML sync workers
• Adds specs to ensure the new and old tables are compatible in all call-sites

During the transition to using the new table, data will be written to both tables so that we can seamlessly enable and disable the feature flag without disruption for users.

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

• original issue: #495499 (closed)
• also implements: #495500 (closed)
• rollout for feature flag: #512497

MR acceptance checklist

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

Screenshots or screen recordings

No user-visible changes

How to set up and validate locally

Before switching to this branch:

1. Ensure you have a SAML provider configured in gitlab.yml , and also the group_saml provider enabled. You may need to be simulating a SaaS instance
2. Go to https://gdk.test:3443/admin/application_settings/general and set up the Azure Integration under "Microsoft Azure Integration" (you do not have to use real values for client-xid and token)
3. Go to the group settings page for a group with SAML SSO configured, for example https://gdk.test:3443/groups/atevans-sso/-/saml and set up the data under "Microsoft Azure Integration"
4. Ensure the data is populated in the system_access_microsoft_applications table

Switch to this branch, and then:

1. Run migrations
2. Ensure the group saml entry in system_access_microsoft_applications is copied to system_access_group_microsoft_applications
3. On the Rails console, load the group and validate that the MicrosoftApplication is reachable:

   group = Group.find_by_path('atevans-sso')
   group.system_access_microsoft_application

4. Update the data for the group's Azure integration, changing the client-xid or graph_endpoint values
5. Validate that the change is written to both tables
6. Enable the feature flag: ::Feature.enable(:group_microsoft_applications_table)
7. Quit and restart the Rails console session to refresh the feature flag cache
8. Validate that the model now returns the new GroupMicrosoftApplication object:

    group = Group.find_by_path('atevans-sso')
   group.system_access_microsoft_application

9. Update the group's "Microsoft Azure Integration" values again in the web UI
10. Validate on the console that the GroupMicrosoftApplication record was updated
11. Validate on the console that the legacy MicrosoftApplication record was also updated

Related to #495499 (closed)

db/post_migrate/20250110233361_split_microsoft_applications_data.rb

@@ -31,6 +31,7 @@ def up
           system_access_microsoft_applications
       WHERE
           namespace_id IS NOT NULL
+      ON CONFLICT DO NOTHING
 
     SQL
 
@@ -54,6 +55,7 @@ def up
           ON gma.temp_source_id = mgat.system_access_microsoft_application_id
       WHERE
           gma.id IS NOT NULL
+      ON CONFLICT DO NOTHING
     SQL
   end