Drop legacy bucket_key/requested_bucket_key columns after #11871 backfill is verified in production

[nbudin]

Follow-up to #11868 / #11871.

That PR adds bucket_id/requested_bucket_id FK columns to signups, signup_requests, signup_ranked_choices, and signup_changes, backfills them, and switches all application code to use them. It intentionally keeps the legacy bucket_key/requested_bucket_key string columns (and the old bucket_key_null_for_non_slot_occupying_states check constraint on signups) in place rather than dropping them in the same release, so that a rolling/partial deploy can't have old code 500 on a missing column while new code is already writing only to the FK columns.

Once the bucket_id-based backfill has been running in production for a while and is confirmed correct, run this migration to drop the legacy columns:

# frozen_string_literal: true
class DropBucketKeyColumnsFromSignupsSignupRequestsSignupRankedChoicesAndSignupChanges < ActiveRecord::Migration[8.1]
  def change
    reversible do |dir|
      dir.up { remove_check_constraint :signups, name: "bucket_key_null_for_non_slot_occupying_states" }

      dir.down do
        add_check_constraint :signups,
                             "(bucket_key IS NULL) OR ((state)::text = ANY (ARRAY['confirmed'::text, 'ticket_purchase_hold'::text]))", # rubocop:disable Layout/LineLength
                             name: "bucket_key_null_for_non_slot_occupying_states"
      end
    end

    change_table :signups, bulk: true do |t|
      t.remove :bucket_key, type: :string
      t.remove :requested_bucket_key, type: :string
    end

    remove_column :signup_requests, :requested_bucket_key, :string

    remove_column :signup_ranked_choices, :requested_bucket_key, :string

    change_table :signup_changes, bulk: true do |t|
      t.remove :bucket_key, type: :string
      t.remove :requested_bucket_key, type: :string
    end
  end
end

Before running it, double check no code still reads/writes the old columns directly (it shouldn't, per #11871's model changes).

Issue written by Claude

[nbudin]

Opened #11878 with this migration, after verifying the #11871 backfill against a fresh production dump (zero mismatches, orphan rate well under 1% and all pre-existing, and confirmed post-deploy writes are FK-only). See the PR for full verification details.

---

Comment written by Claude