Backfill epic attributes directly into issues table
### Task Statement This backfilling task is handling the backfilling of the basic fields from legacy `epics` table into `issues` table. ### Basic Epic Fields The basic fields that this backfilling migration is going to be copying from `epics` table are: ``` group_id author_id iid cached_markdown_version updated_by_id last_edited_by_id lock_version last_edited_at created_at updated_at title title_html description description_html closed_by_id closed_at relative_position state_id confidential external_key ``` ### Notes about the migration: 1. Iterate over all records in `epics` table that have `issue_id IS NULL`. Records in `epics` table where `issue_id IS NOT NULL` should already have a corresponding record in the `issues` table 1. Optionally we can iterate over the records in the `epics` table where `issue_id IS NOT NULL` and check that the data between epic record ant its corresponding issues record is in sync. But this is OPTIONAL and is not the main purpose of this task. 2. Create a record for each of those epic records where `issue_id IS NULL` in the issues table by copying over data from the list of fields above. 3. Backfill the corresponding `epics.issue_id` value into the `epics` table for each of the records previously created in the `issues` table ### Other considerations 1. Consider iterating over `epics` table in batches, see batched [background migrations docs](https://docs.gitlab.com/ee/development/database/batched_background_migrations.html) for reference 2. Consider using bulk inserts into issues table and bulk updates over epics table 3. Note that issues table is a high traffic table, so any exclusive locks should be as short as possible and also potential race condition should be taken into account.
epic