Once the new scheduler pattern is deployed.
We'll need to align the origin_visit_status data records to actually have their type filled in.
That means:
- modify the schema to add the visit_type column
- sql file to migrate the data from origin_visit to origin_visit_status
- ~~Check impacts on storage clients (i.e. loaders)~~ (already dealt with indeed)
Data to migrate 1239705800 rows out of 1259171054:
```
Production status (mirror):
#+begin_src sql
softwareheritage=> select now(), count(*) from origin_visit_status;
now | count
-------------------------------+------------
2021-02-02 09:47:15.904791+00 | 1259171054
(1 row)
softwareheritage=> select now(), count(*) from origin_visit_status where type is null;
now | count
-------------------------------+------------
2021-02-02 09:53:08.903614+00 | 1239705800
(1 row)
#+end_src
```
Deliverables migrate both:
- [x] staging db (as it will be used to exercise the migration script and it must be up-to-date as well)
- [ ] production db (in progress, details below)