Fix#4110 by adding an option to control the preloading of video data on
page load. If disabled ("false"), the browser will not preload any video
data until the user explicitly hits the "Play" button.
If enabled ("true"), the default behavior will be used, which means the
browser decides how much of the video will be preloaded.
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