Each job can define its own config options, that will be automatically
added to the global YAML config structure.
By default, all jobs get an "enable" property that can prevent a specific
job from running, e.g if the instance admin wants to manage the database
cleaning by themselves.
Unlike the other migrations, this one uses a bare table name to specify the table. This means it looks in the default search path. Unfortunately, the out of box search path is:
1. Schema with the same name as the user
2. Public
Because of this, if a schema exists with the same name as the DB user, the playlist_videos table will get created in _that_ schema, rather than the public schema, and then the grant statement will fail with an error like below if check_table is enabled as it keeps trying to create the table but failing on the grant statement:
```
2022-01-22 02:27:42 UTC [info] check_table: check_table: CREATE TABLE playlist_videos
Unhandled exception: relation "public.playlist_videos" does not exist (PQ::PQError)
from /usr/share/crystal/src/primitives.cr:266:3 in 'handle_error'
from lib/pg/src/pq/connection.cr:184:9 in 'handle_async_frames'
from lib/pg/src/pq/connection.cr:162:7 in 'read'
from lib/pg/src/pq/query.cr:53:14 in 'exec_all'
from lib/db/src/db/database.cr:126:9 in '__crystal_main'
from /usr/share/crystal/src/crystal/main.cr:110:5 in 'main'
from src/env/__libc_start_main.c:94:2 in 'libc_start_main_stage2'
2022-01-22 02:27:43 UTC [info] check_table: check_table: CREATE TABLE playlist_videos
Unhandled exception: relation "public.playlist_videos" does not exist (PQ::PQError)
from /usr/share/crystal/src/primitives.cr:266:3 in 'handle_error'
from lib/pg/src/pq/connection.cr:184:9 in 'handle_async_frames'
from lib/pg/src/pq/connection.cr:162:7 in 'read'
from lib/pg/src/pq/query.cr:53:14 in 'exec_all'
from lib/db/src/db/database.cr:126:9 in '__crystal_main'
from /usr/share/crystal/src/crystal/main.cr:110:5 in 'main'
from src/env/__libc_start_main.c:94:2 in 'libc_start_main_stage2'
```
* Untrack config.yml
`config/config.yml` has been untracked and moved to `config/config.example.yml`.
The Dockerfile has been updated to copy all `config/config.*` files and to try
to move `config/config.example.yml` to `config/config.yml`. If a user supplied
`config/config.yml` exists it is not overwritten.
* Update Dockerfile to use `shard.lock`
* Fix tests
