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