Drop principal_id from CD transition tables

What does this MR do and why?

Drop the unused principal_id column from the two CD transition tables:

• cd_deployment_transitions
• cd_rollout_transitions

principal_id is a leftover from the old polymorphic principal_type + principal_id actor. The actor is now recorded in the principal string column (renamed from principal_type), so principal_id is no longer read or written. It was added to ignore_column in 19.3, a milestone before this 19.4 drop, so these post-deployment drops are safe.

The column has no index and no foreign key, so each table needs only a single remove_column migration.

The ignore_column :principal_id entries are intentionally kept in the models here and removed in a follow-up milestone, once these drops have deployed (the ignore must outlive the drop to avoid selecting a dropped column during the rolling deploy).

Data deletion

• What's deleted: only the unused principal_id column on cd_deployment_transitions and cd_rollout_transitions.
• Recovery: the migrations are reversible; down re-adds the column. The old column values are not recoverable, but principal_id has been unused since the actor moved to the principal column, so there is nothing functional to recover.
• Records affected: these CD tables are behind a feature flag and hold a small number of rows on GitLab.com; the dropped column is unused.
• User experience impact: none. principal_id is not read or written anywhere.

Note on db:check-migrations

This check reports a known false positive for column drops: rolling the migration down re-adds principal_id at the end of the table rather than its original position, so the rolled-back structure.sql doesn't match master. Safe to apply pipeline:skip-check-migrations label.

References

• https://gitlab.com/gitlab-org/gitlab/-/work_items/627880

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.