Currently the next-gen scheduler runners in charge of scheduling recurring visits for
origins are triggered on the scheduler machines per environment [1]. They are managed
individually and manually through a cli call for each type of visits (and eventually per
lister).
We need to replace those with a new module which does not exist yet, the orchestrator.
That module would be in charge of regularly schedule origins of a given type according
to the scheduler metrics available. Deployment wise, that'd be a systemd service that
would launch it.
Its scheduling algorightm would follow something along those lines:
```
for each visit type:
- queue filled-in: monitored, when under a given threshold event is reached,
this triggers a fill-in the void state. goto "fill-in the void state"
- fill-in the void state:
for each policy (according to ratio [1]) for that visit type:
- fetch origins and schedule
- continue until threshold is reached or policy has no results
- when threshold is reached, goto "queue filled-in"
```
[1] Ratio could be:
```
|----------------------------------------------------------------+-----------------------------------+-------|
| visit_type | scheduling policies | ratio |
|----------------------------------------------------------------+-----------------------------------+-------|
| package-loader: archive, cran, debian, npm, nixguix, pypi, ... | already_visited_order_by_lag | 50 |
| | never_visited_oldest_update_first | 50 |
|----------------------------------------------------------------+-----------------------------------+-------|
| git, svn, hg | already_visited_order_by_lag | 49 |
| | never_visited_oldest_update_first | 49 |
| | origins_without_last_update | 2 |
|----------------------------------------------------------------+-----------------------------------+-------|
```
[1] root tmux session in:
- prod: saatchi
- staging: scheduler0