Migrate traces to a new path

We merged this MR: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11824. And want to finish now https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11641, as I know that this is needed for merging the foreign keys consistency fix. Looking that previous artifacts migration took around 200s on GitLab.com to migrate 400 artifacts, and given that finding, boundaries took around 50s, it seems that we were able to move about 2.6 artifacts per-sec on thread.

Given that we have to go through 450.000 builds and move their traces it will take around 173.000s, so around 48 hours. It seems to be an ideal case for Background Migration. The only problem with Background Migration that it doesn't store a state, as the location of the file is deduced automatically, based on the existence of file. If we will have to use Background Migration we would have to introduce temporary column to store an information about which traces were migrated, to in case of sidekiq failure to let us know exactly which ones we should still touch.

Following our release cycle:

1. Release 1:

• introduce traces_migrated:bool, default: nil,
• use the same heuristic as for artifacts: https://gitlab.com/gitlab-org/gitlab-ce/issues/32036#note_30422470,
• create post_migrate that triggers Background Migration for each build,
• run Background Migration and move traces, marking traces_migrated: true,

2. Release 2:

• prepare regular migration that looks for all rows with traces_migrated: nil and uses the same heuristic: https://gitlab.com/gitlab-org/gitlab-ce/issues/32036#note_30422470,
• remove Background Migration,
• in post deploy remove traces_migrated column,

It will take a few days to actually run it, so it will be a slow-running process.

@yorickpeterse @grzesiek What do you think about that?